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SECTION  1.  GENERAL  DESCRIPTION 


1 . 1 Purpose  of  the  Program  Maintenance  Manual . The  objective 
for  writing  this  Program  Maintenance  Manual  for  the  AUDIT 
system  is  to  provide  the  maintenance  programmer  personnel  with 
the  information  necessary  to  effectively  maintain  the  system. 

1.2  System  Application.  The  AUDIT  system  examines  FORTRAN 

computer  programs  or  modules  developed  under  the  SESCOMP 
system  for  compliance  with  cer ta  i n^  pr escr i bed  standards  (as 
set  forth  in  the  SESCOMPSPEC ' s ' ■’ ) and  produces  reports 

detailing  the  deviations  from  those  standards.  The  AUDIT 
system  also  examines  a program  unit  (mam  program  or  subpro- 
gram) to  detect  and  report  the  existence  of  any  undefined 
variables  along  the  program  unit's  possible  paths.  AUDIT 
provides  the  user  with  an  option  which  allows  him  to  test  the 
effect  of  changes  in  word  length  on  the  output  of  computer 
prog  r ams . 

1.3  Equipment  Environment.  The  AUDIT  system  is  operational 

on  three  processors:  CDC  6U00  series,  UNIVAC  1108,  and  IBM 

360.  AUDIT  uses  the  following  operating  systems:  CDC  SCOPE 

3.4,  UNIVAC  EXEC-8,  and  IBM  OS-360. 

AUDIT  IS  available  on  tape  for  each  of  the  three  proc- 
essors and  on  disk  for  the  CDC  6600  at  DTNSRDC.  Card  decks 
for  each  of  the  processors  are  also  available.  The  mode  of 
operation  of  the  AUDIT  system  is  controlled  by  card  input. 

The  programs,  modules,  or  subprograms  to  be  examined  by 
AUDIT  may  be  entered  via  cards,  tape,  or  disk.  The  results 
of  AUDIT  which  are  of  concern  to  the  user  are  produced  as 
printout. 

1.4  Program  Environment.  The  AUDIT  system  was  designed  to 
examine  software  developed  under  the  SESCOMP  system.  SESCOMP, 
an  acronym  for  Surface  Effect  Ship  Computations,  is  the  name 
of  a system  for  procuring  and  managing  modular  computer  pro- 
grams developed  for  the  Naval  Sea  System  Command's  Surface 
Effects  Ship  Project  Office  (PMS304).  The  background,  objec- 
tives, and  content  of  SESCOMP  are  described  in  Cuthbert,  et  al.*’ 
Although  it  is  not  required  that  the  user  of  AUDIT  have  an 
understanding  of  the  SESCOMP  system,  a basic  knowledge  of  that 
system  would  help  him  to  use  AUDIT  more  effectively.  AUDIT 

may  be  used  to  examine  any  FORTRAN  software,  not  just  the 
SESCOMP-produced  software.  The  following  attributes  of  the 
AUDIT  system  will  aid  users  in  producing  more  reliable  soft- 
ware: 
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(1)  The  flow  analysis  feature  examines  a piogi  am  unit's 
paths  to  detect  the  use  of  undefined  variables. 

(2)  The  variable  precision  feature  enables  the  user  to 
test  the  effect  of  changes  in  word  length  on  the 
output  of  a computer  program. 

(3)  All  aspects  which  affect  portability  among  the  four 
SESCOMP  processors  are  examined. 

The  analytic  capability  of  the  AUDIT  system  combines 
with  the  SESCOMP  programming  standards  to  facilitate  the 
pioduction  of  more  reliable  softwaie,  as  detailed  in  Culpeppei 

1 . 5 Convent  ions . Section  2 contains  a detailed  description 
of  the  AUDIT  software  and  modes  of  operation.  Section  3 con- 
tains a detailed  description  of  the  input  and  output  conven- 
tions. Section  4 describes  the  operating  procedure  for  all 
modes  of  operation  of  the  AUDIT  system.  The  listings  of  the 
AUDIT  software  for  each  of  the  three  processors  are  each 
separately  bound  in  Appendixes  B,  C,  and  D. 


SECTION  1. 


SYSTEM  DESCRIPTION 


2.1  ^Genet^al  Descr  ipt  ion . The  Naval  Sea  System  Command's 

Surface  Effect  Ship  Project  Office  (PMS304)  requested  the 
Computation  and  Mathematics  Department  of  the  David  W. 

Taylor  Naval  Ship  Research  and  Development  Center  to  develop 
computer  software  that  would  examine  vendor -pr od uced  computer 
programs  or  modules  for  compliance  with  the  SESCOMPSPEC ' s 
and  would  produce  reports  detailing  the  deviations.  AUDIT, 
the  computer  software  developed  to  carry  out  these  functions, 
has  four  modes  of  operation.  In  the  first,  or  auditing  mode, 
AUDIT  examines  a program  unit  for  conformance  with  the  set  of 
SESCOMPSPEC  programming  standards  and  issues  a report  detail- 
ing the  deviations  from  those  standards.  In  the  second,  or 
roll  call  mode,  AUDIT  examines  a module  for  deviations  from 
SESCOMF's  roll  call  specifications  (see  Section  2.10  of 
SESCOMPSPEC  5 . In  the  third,  or  variable  precision  mode, 

AUDIT  tests  the  effect  of  changes  in  word  length  on  the  output 
of  a computer  program.  In  the  fourth,  or  flow  analysis  mode, 
AUDIT  examines  a program  unit  to  detect  and  report  the 
existence  of  any  undefined  variables  along  the  program  unit's 
possible  paths. 

An  important  feature  of  AUDIT  is  the  parser  software, 
which  checks  expressions  to  see  if  they  are  syntactically  and 
semantically  correct.  The  parser  software  uses  a syntax 
graph  to  define  the  legal  grammar  for  expressions. 

2.1.1  Aud it  Mode . The  audit  mode  of  AUDIT  examines  a pcogram 

unit  for  adherence  to  the  specifications  in  SESCOMPSPEC!'^, 
SESCOMPSPEC4  and  SESCOMPSPEC5  However,  not  all  of  the 
specifications  are  examined.  Sections  2. 1.1.1,  2. 1.1. 2,  and 
2. 1.1. 3 indicate  which  specifications  are  (or  are  not)  checked 
by  AUDIT. 

2. 1.1.1  SESCOMPSPEC!  Elements.  The  various  sections  of 
SESCOMPSPEC!  are  considered  in  turn.  AUDIT  checks  all  of  the 
SESCOMPSPEC!  specifications  (and  therefore  the  Standard) 
except  as  noted  following.  Comments  are  also  m.ade  to  amplify 
what  is  checked.  The  user  himself  must  assume  responsibility 
for  checking  the  areas  not  covered  by  AUDIT. 

2. 1.1. 1.1  Program  Form.  A diagnostic  is  issued  when  a non- 
FORTRAN  character  is  encountered.  All  elements  of  the 
Standard  concerning  lines  are  enforced  and  appropriate  diag- 
nostics are  issued  for  violations. 

2 . 1 . 1 . 1 . 2  Data  Types.  All  data  types  permitted  by  the 

Standard  are  recognized.  Only  characters  of  the  FORTRAN 
character  set  are  permitted  as  Hollerith  types. 
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L'jLi  ^ _ D^ta  and  Procedure  Identification.  The  magnitudes 

ot  integer,  real,  double  precision,  and  complex  constants 
are  not  checked  by  the  IBM  360  version  of  AUDIT.  AUDIT  does 
not  check  whether  a dummy  argument  of  an  external  procedure 
identifies  a subroutine  or  external  function  not  referenced 
in  the  program  unit  being  analyzed.  If  a dummy  argument  of 
a program  unit  bears  the  same  symbolic  name  as  a subroutine 
or  external  function  referenced  within  the  program  unit  being 
analyzed,  a diagnostic  on  the  violation  is  issued. 

2. 1.1. 1.4  Expressions.  AUDIT  does  not  check  the  requirement 
that  no  factor  may  be  evaluated  that  requires  raising  a zero 
valued  primary  to  a zero  valued  exponent. 

2. 1.1. 1.5  Statements.  AUDIT  does  not  check  the  requirement 
that  the  integer  variable  i in  an  assigned  GO  TO  of  the  form 

GO  TO  i,  (k],  k2,  kj^  ) has  been  assigned  one  of  the 

statement  labels  in  the  parenthesized  list  by  an  ASSIGN  state- 
ment prior  to  the  execution  of  the  subject  statement. 

In  a computed  GO  TO  of  the  form  GO  TO  (kj,  k 2»  

kp),  i AUDIT  does  not  ensure  that  i has  been  given  a value  j, 
Ij.n,  prior  to  execution. 

In  a DO  statement  of  the  form  DO  n i=m|,  mT,  (m-) , if  m^, 
m , and/or  m-  are  variables,  AUDIT  does  not  check  any  of  the 
following  restrictions: 

(1)  At  time  of  execution  of  the  DO  statement,  mi,  m2f 
m must  be  greater  than  zero. 

(2)  The  terminal  parameter  (mT)  must  be  no  less  than  the 
initial  parameter  (m|). 

(3)  The  sum  of  the  terminal  parameter  and  the  incremen- 
tation parameter  minus  one  may  not  exceed  2**17-2. 

The  above  three  restrictions  are  checked  if  m|,  m and/or 
m^  are  integer  constants. 

AUDIT  does  not  check  whether  an  array  elemen*  name 
contains  a variable  subscript  that,  during  execution  of  the 
program  unit,  assumes  a value  less  than  one  or  larger  than 
the  maximum  length  specified  in  the  array  declarator.  For 
array  element  names  having  an  integer  constant  subscript, 

AUDIT  does  not  check  for  a zero  subscript  but  does  check  for 
a subscript  that  is  less  than  zero.  AUDIT  does  check  an 
integer  constant  subscript  for  exceeding  the  maximum  length 
but  does  this  only  for  non-executable  statements  (DATA  and 
EQUIVALKNCE) . 

AUDIT  does  not  check  that  a formatted  READ  or  WRITE 
statement  may  not  read  or  create  a record  of  more  than  120 
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characters.  It  does  not  check  that  the  first  character  of 
a formatted  record  for  printinq  may  not  be  a +. 

AUDIT  does  not  check  that  a FORMAT  statement  that  is 
used  for  both  input  and  output  must  end  with  a field  descriptor 
or  group  of  field  descriptors.  If  there  is  an  input/output 
list  for  a formatted  READ  or  WRITE,  AUDIT  does  not  check  that 
at  least  one  field  descriptor  other  than  nH  or  nX  must  exist. 

L*  L:  L*  ^ Pi'ocebures  and  Subprograms.  For  a FUNCTIOi^  state- 
ment of  the  form  t FUNCTION  f (a^,  a 2t  a^)  or  a 

SUBROUTINE  statement  of  the  form  SUBROUTINE  s (a^,  a?,  

a , AUDIT  checks  that  the  a's,  the  dummy  arguments,  are  each 
either  a variable  name  or  an  array  name  but  does  not  check  that 
a dummy  argument  is  not  an  external  procedure  name  not  lefer- 
enced  in  the  program  unit  being  analyzed.  If  a dummy  argument 
of  a program  unit  bears  the  same  symbolic  name  as  a subroutine 
or  external  function  referenced  in  the  program  unit  being 
analyzed,  a diagnostic  on  the  violation  is  issued. 

AUDIT  checks  the  dummy  arguments  of  FUNCTION  and  SUBROU- 
TINE statements  and  the  actual  arguments  used  for  referencing 
external  functions  and  subroutines  to  insure  that  the  argu- 
ments agree  in  order,  number,  type,  and  dimensionality  with 
the  argument  definition  in  the  SESCOMP  Interface  Definition 
file  (see  Section  3. 2. 1.3). 

For  a function  subprogram  AUDIT  does  not  check  whether 
the  subprogram  contains  a statement  that  directly  or  indirectly 
references  the  function  being  defined. 

The  following  is  not  checked:  If  a function  reference 

causes  a dummy  argument  in  the  referenced  function  to  become 
associated  with  another  dummy  argument  in  the  same  function 
or  with  an  entity  in  common,  a definition  of  either  within 
the  function  is  prohibited. 

2 . 1 . 1 . 1 . 7 Pr  og  r ams . The  normal  execution  sequence  is  enforced 

by  the  flow  analysis  mode  of  AUDIT  (see  Section  2.1.4). 

2_,  1 .1.1.8  Intra-  and  Inter-Prog  ram  Relationships.  In  the 
flow  analysis  mode,  AUDIT  traces  the  definition  and  redefinition 
of  each  variable  in  a program  unit  through  all  the  possible 
program  paths. 

2. 1.1. 2 SESCOMPSPEC4  Elements.  The  following  SESCOMPSPEC4 
requirements  are  checked  by  AUDIT. 

2 . 1 . 1 . 2 . 1 Usage  . The  symbolic  name  of  the  subprogram  being 
analyzed  is  checked  to  insure  that  the  name  is  in  the  Interface 
Definition  file  (see  Section  3. 2. 1.3).  The  subprogram  dummy 
arguments  ( if  any)  are  checked  to  see  if  they  agree  in  order. 


number,  type,  and  dimensionality  with  the  subprogram's 
argument  list  as  defined  in  the  Interface  Definition  file. 

If  the  subprogram  is  a function  subprogram,  the  type  is 
checked  with  the  Interface  Definition  file. 

2 . 1 . 1_._2_._2  Labeled  COMMON  Storage.  The  symbolic  name  of 
each  labeled  COMMON  block  is  checked  to  insure  that  the 
name  is  in  the  Interface  Definition  file. 

2 . 1_.  1 . Category  1 COMMON  Storage.  The  size  and  type  of 

each  variable  of  a Category  1 labeled  COMMON  block  is  checked 
with  the  Interface  Definition  file. 

z .1  . 1_._;^.  4 Category  2 COMMON  Storage.  AUDIT  checks  that,  for 

each  Category  2 labeled  COMMON  block,  the  elements  are  grouped 
by  type.  AUDIT  also  checks  that  a module  has  at  least  one 
Category  2 block. 

2. 1.1. 2. 5 Blank  COMMON  Storage.  If  a module  has  blank  COMMON 
storage,  AUDIT  checks  that  the  size  of  the  blank  COMMON  storage 
agrees  with  the  size  specified  in  the  Interface  Definition  file. 

2 . 1 . 1 . J SESCOMPSPEC5  Elements.  The  following  SESC0MPSPEC5 

requirements  are  checked  by  AUDIT. 

2. 1.1. 3.1  BLOCK  DATA.  For  a BLOCK  DATA  subprogram,  the  pre- 
scribed order  of  data  types  in  a labeled  COMMON  block  are 
checked  . 

2 . 1 . 1 . 3 . 2  COMMON  Storage.  The  Category  1 labeled  COMMON  block 

SESCOM  is  checked  to  insure  that  the  symbolic  names  assigned 

to  each  element  of  the  block  are  the  prescribed  names.  Each 
program  unit  is  checked  to  see  if  it  contains  the  mandatory 
Category  1 block  SESCOM.  In  this  case  AUDIT  does  not  distin- 
guish whether  the  program  unit  being  checked  is  a main  program, 
module  root  program  unit,  ancillary  subprogram,  or  extraordinary 
subroutine.  The  user  should  disregard  the  mandatory  SESCOM 
diagnostic  message  if  an  ancillary  subprogram  or  extraordinary 
subroutine  START  does  not  contain  the  SESCOM  block. 

For  Category  2 and  3 labeled  COMMON  blocks,  AUDIT  checks 
that  each  and  every  element  of  each  block  is  used  by  the  sub- 
program. For  modules  with  ancillary  program  units  a misleading 
message  may  be  issued.  Since  the  audit  mode  analyzes  only  a 
single  program  unit,  there  is  no  way  of  knowing  if  an  element 
in  a Category  2 or  3 block  is  used  in  another  program  unit  of 
the  module.  AUDIT  also  checks  that  a module  has  at  least  one 
Category  2 labeled  COMMON  block. 

If  a module  has  blank  COMMON  storage,  AUDIT  checks  that 
the  size  of  blank  COMMON  storage  agrees  with  the  size  speci- 
fied in  the  Interface  Definition  file. 
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2 ■ I . 1 . 3 . j Ancillary  Subprograms.  The  symbolic  name  of  each 

ancillary  subpro>gram  is  checked  to  insure  that  the  name  is  in 
the  Interface  Definition  file  (see  Section  3. 2. 1.3). 

2 . 1 . 1 . 3 . 4 Rol  1 Call.  AUDIT'S  roll  call  mode  performs  an 

analysis  of  a module's  roll  call  actions  (see  Section  2.1.2). 

2. 1.1. 3. 5 Order  of  Statements.  The  prescribed  order  of 
statements  is  checked. 

2.1.2  Roll  Call  Mode.  AUDIT  contains  two  options  for  checking 

the  roll  call  action  of  the  i;oot  program  unit  of  a module.  See 
Section  2.10  of  SESCOMPSPEC5  for  an  explanation  of  a module's 
roll  call  act  ions  . 

( 1 ) Opt  ion  1 : AUDIT  simulates  the  modules  root  program 

unit  execution  by  executing  the  program  unit  for  mode 

index  values  of  0,  -1,  -11,  -12  (a  use  count  index 

of  1 is  assumed).  The  output  for  each  mode  index  is 
printed.  The  mode  index  value  and  the  output  device 

(X,  Y,  or  Z)  is  designated  for  each  output  of  a specific 
mode  index  value.  For  each  mode  index  value,  AUDIT  also 
checks  that  each  module  referenced  by  the  root  program 
unit  is  referenced  in  the  same  roll-call  mode. 

(2)  Option  2:  For  each  mode  index  value  (0,  -1,  , 

-11,  -12),  AUDIT  checks  that  each  module  referenced  by 
the  root  program  unit  is  referenced  in  the  same  roll-call 
mode . 

If  an  ancillary  subprogram  of  a module  references  a 
module  (A)  not  referenced  by  the  root  program  unit  of  the 
module  (for  computational  mode)  and  this  module  (A)  is  not 
referenced  in  the  roll-call  mode  of  the  root  program  unit, 

AUDIT  does  not  detect  this  deviation  from  the  roll  call  speci- 
fications. The  roll  call  mode  uses  subroutines  CMPARE,  MODID, 
and  ROLCHK,  and  generates  main  program  ROLCAL. 

The  roll  call  mode  should  only  be  used  to  examine  the 
root  program  unit  of  a SESCOMP  module. 

2.1.3  Variable  Precision  Mode.  If  a contractor  develops  a 

program  on  a computer  with  a word  length  of  60  bits,  it  is 
important  to  determine  whether  it  will  produce  correct  results 
on  a computer  with  a smaller  word  length.  The  AUDIT  system 
provides  a mechanism  to  assist  in  this  determination.  The 
variable  precision  mode  allows  the  user  to  specify  one  of  a 
group  of  truncation  operators  to  be  applied  after  each  arith- 
metic operation.  These  truncation  operators  are  in  the  form 
of  variable  precision  function  subprograms:  QICOMP,  QlDPRE, 

and  QIREAL  (see  Section  2.2.68).  There  are  sets  of  truncation 
operators  for  the  results  of  operations  on  real,  complex,  and 
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double  precision  numbers.  Tne  user  selects  the  appropriate 
operator  from  each  set  to  provide  the  desired  degree  of 
precision.  The  truncation  operators  simulate  word  lengths 
ot  30  to  40  bits,  24  to  31  bits,  and  30  to  35  bits  for  the 
CDC  bOOO,  IBM  360,  and  UNIVAC  1108,  respectively.  The  ref- 
erence to  the  truncation  operator  following  each  arithmetic 
operation  is  inserted  by  AUDIT  in  the  modified  statements. 

Only  two  types  of  statements  are  modified,  assignment  state- 
ments and  CALL  statements. 

An  assignment  statement  is  of  the  form  V=E  where  V is 
a variable  name  or  array  element  name  and  E is  an  arithmetic 
expression.  AUDIT  examines  the  arithmetic  expression  from 
right  to  left  for  triples  of  the  form  SAE | OP  SAE7  where  OP 
may  be  +,  -,  *,  or  / and  SAE  is  any  valid  FORTRAN "expr ess  ion . 
Each  triple  is  rewritten  in  the  form  Fj  (SAE]  OP  SAE  i ),  where 
F j is  QIREAL,  QICOMP,  or  QlDPRE,  depending  on  whether"  the 
result  of  SAE  I OP  SAE is  real,  complex,  or  double  precision, 
respectively.  The  following  example  illustrates  the  method; 

Given:  Y=A*B  + C*D 

Result:  Y=Q1 REAL ( Q1 REAL( A*B ) + Q1REAL(C*D)) 

A CALL  statement  is  of  the  form  CALL  PROG  ( Aj  , A-,,  

A ) where  A]  are  actual  arguments.  AUDIT  examines  each 
actual  argument  and  generates  a new  CALL  statement  as  follows: 

(1)  Constants,  variable  names,  array  element  names,  and 
array  names  are  copied  unchanged. 

(2)  FORTRAN  expressions  are  processed  as  for  assignment 
statements . 

The  following  example  illustrates  the  method; 

Given:  CALL  PROG  (A,  A(l,2),  B,  C+D) 

Result:  CALL  PROG  (A,  A(l,2),  B,  QIREAL  (C+D)) 

where  A is  an  array  and  B,  C,  and  D are  real  variables. 

The  variable  precision  technique  is  not  intended  to 
simulate  the  arithmetic  peculiarities  of  any  particular 
computer.  Its  only  purpose  is  to  permit  the  precision  of 
arithmetic  operations  on  a given  computer  to  be  varied. 

With  this  restriction  in  mind,  the  technique  as  implemented 
in  AUDIT  has  one  limitation: 

. The  calculations  of  FORTRAN  library  functions  and  of 
any  subprogram  not  processed  by  AUDIT  are  not  subjected 
to  tr  uncat  ion . 

2.1.4  Flow  Analysis  Mode.  The  tlow  analysis  mode  of  AUDIT 
detects  violations  of  ANSI  FORTRAN  ^ wh  ich  are  concerned  with 
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inter-  and  intra-program  relationships.  In  the  design  of 
the  AUDIT  system  particular  attention  was  paid  to  that 
section  of  the  ANSI  Standard  which  deals  with  the  definition 
and  "undefinition"  of  variables.  This  section  states,  for 
example,  that  if  two  variables  of  different  types  become 
associated  by  appearing  in  an  EQUIVALENCE  statement  and  one 
of  the  variables  becomes  defined,  the  other  becomes  undefined 
and  may  not  be  used  in  computation  until  redefined.  The  flow 
analysis  is  performed  using  some  results  obtained  from  the 
theory  of  compiler  optimization  provided  in  Allen^  and 
Kennedy  ' . During  the  interstatement  analysis  of  a program 
unit,  AUDIT  constructs  the  usual  tables  containing  information 
about  the  variable  names  and  their  associations  through  COMMON 
and  EQUIVALENCE  statements.  In  addition  a set  of  basic  blocks 
is  constructed.  A basic  block  starts  with: 

(1)  the  first  executable  statement  of  the  program  unit, 
or 

(2)  a labeled  executable  statement,  or 

(3)  the  first  executable  statement  after  a RETURN,  STOP, 
GO  TO,  or  logical  IF  containing  one  of  these  forms, 
or 

(4)  the  first  statement  after  a DO  or  DO  terminal  state- 
ment. 

A basic  block  ends  with: 

(1)  any  GO  TO,  STOP,  RETURN,  or  logical  IF  containing 
one  of  these  forms,  or 

(2)  a DO  or  DO  terminal  statement. 

A control  flow  graph  is  constructed  using  basic  blocks  as 
nodes  and  the  control  flow  paths  as  edges.  In  the  implemen- 
tation of  AUDIT,  the  information  retained  in  the  block  con- 
sists of  the  names  of  the  variables  defined  or  undefined  by 
the  basic  block  and  the  names  of  the  variables  which  must 
be  defined  prior  to  execution  of  the  block.  The  symbol  table 
is  used  to  record  the  status  of  each  variable,  e.g.,  whether 
it  is  defined,  undefined,  an  induction  variable,  or  an  ASSIGNed 
variable.  Each  path  in  the  graph  is  traced  through  to  detect 
and  report  improper  use  of  undefined  variables.  A depth-first 
graph  tracing  algorithm  is  employed.  In  order  to  detect 
infinite  loops  and  to  facilitate  diagnostic  messages,  a list 
of  the  basic  block  names  in  the  path  currently  being  tra- 
versed is  maintained.  As  each  new  name  is  added  to  the  list, 
the  number  of  prior  occurrences  of  that  name  is  determined. 

When  the  count  exceeds  two,  tracing  of  that  path  terminates 
and  tracing  of  the  next  path  begins.  This  heuristic  seems 
satisfactory  for  the  sort  of  programs  normally  produced  by 
engineers.  In  a fairly  complex  program,  however,  it  is 
possible  that  some  legitimate  paths  may  be  missed.  DO  loops 
are  traced  only  once.  The  flow  graph  is  also  analyzed  to 


insure  proper  nesting  of  DO  loops  and  to  detect  illegal 
branches  within  DO  loops.  Subprogram  references  are 
checked  to  insure  that  the  actual  parameters  are  defined 
before  the  reference  (for  input  parameters)  and  after  the 
reference  (for  output  parameters). 

The  flow  analysis  mode  has  two  options:  a full  flow 

analysis  and  a moderate  flow  analysis.  The  full  flow  ana- 
lysis allows  a path  to  have  a statement  label  that  appears 
at  most  twice.  The  moderate  flow  analysis  does  not  check 
any  path  in  which  a statement  label  appears  more  than  once. 
Given  the  following  coding: 

1 = 0 
J = 0 

5 1=1+1 

CALL  SUB( I ) 

IF( I .LT.IO)  GO  TO  5 
10  J=J+1 

CALL  SUBB(J) 

IF(J. LT.IO)  GO  TO  10 

RETURN 

END 

the  moderate  flow  analysis  would  check  only  one  path: 

(5.10) .  The  full  flow  analysis  would  check  four  paths: 

(5.10) ,  (5,5,10),  (5,5,10,10),  and  (5,10,10). 

The  moderate  flow  analysis  will  usually  check  less 
paths  than  the  full  flow  analysis.  The  full  flow  analysis 
should  be  satisfactory  for  most  program  units.  However, 
the  moderate  flow  analysis  is  less  time-consuming  and 
should  be  used  if  the  full  flow  analysis  is  taking  too  much 
t ime . 

2.1.5  Parser  Software.  Arithmetic  expressions,  logical 
expressions,  and  I/O  lists  are  parsed  by  AUDIT.  Parsing 
involves  determining  whether  an  expression  is  syntactically 
and  semantically  correct.  The  software  used  to  parse 
expressions  is  called  the  parser. 

Part  of  the  AUDIT  parser  is  written  in  GIRL  (Graph 
Information  Retrieval  Language),  which  is  a high-level 
language  developed  at  DTNSRDC  and  described  in  BerkowitzH. 
The  GIRL-coded  statements  are  translated  into  FORTRAN  code 
by  running  the  GIRL  statements  through  the  GIRL  preprocessor. 
This  FORTRAN  code  thus  generated  (and  six  other  FORTRAN  sub- 
routines) is  the  parser  software  for  AUDIT. 

The  parser  requires  a syntax  graph  as  input.  This  graph 
is  a plex  data  structure  which  completely  defines  all  valid 
arithmetic  and  logical  expressions,  as  well  as  I/O  lists. 
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The  parser  can  conveniently  manipulate  graph  structures, 
i.e.,  insert,  identify,  retrieve,  delete,  and  compare  node- 
link-node triples  such  as  the  one  shown  following: 

B 

(single-value  list) 

where  A is  the  source  node 
B is  the  link 
and  C is  the  sink  node. 

Source  nodes  and  links  are  random  numbers  generated  by 
SUBROUTINE  LVGRN.  Sink  nodes  may  be  random  numbers,  integers, 
or  Hollerith  data.  The  triple  can  also  be  the  component  of 
a multi-value  list  represented  in  either  of  two  ways. 
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The  syntax  graph  is  composed  of  single-value  lists  and  multi- 
value lists  linked  together.  The  triples  themselves  are 
stored  in  a structure  called  GIRS  (Graph  Information  Retrieval 
System)  memory  according  to  the  following  algorithm: 

LOG  = (A+B)  modula  MEMSZE. 

B 

For  example,  the  triple  01  where  A=52,  B=73,  and 

MEMSZE  (GIRS  memory  size)=100,  will  be  stored  in  GIRS  location 
25.  LOC=(52+73)  mod  lOU  = 125  mod  100  = 25. 

The  GIRS  memory  is  constructed  in  the  following  way. 

Each  single-value  list  requires  four  locations;  each  multi- 
value list  requires  4(n+l)  locations  (where  n^2  is  the  number 
of  sink  nodes).  The  GIRS  memory  is  stored  in  COMMON  blocks 
LVVTRl , LVVTR2,  LVVTR3 , and  LVVTR4 . 

The  syntax  graph  is  composed  of  nodes  and  links.  Each 
node  is  a state  in  the  graph.  The  parsing  of  an  expression 
proceeds  from  state  to  state  by  way  of  the  links.  Each  link 
is  either  a terminal  symbol  or  STOP,  ASSOC,  or  LEVEL.  A 
terminal  symbol  is  one  of  the  following:  PLUS,  MINUS,  SLASH, 

LPAR,  RPAR,  COMMA,  STAR,  EXP,  LT , LE,  GT,  GE,  EQ,  NE,  OR, 

AND,  NOT,  EQUALS,  OPRAND.  A constant  or  a variable  is  desig- 
nated OPRAND.  Each  node  and  link  is  identified  by  a unique 
pseudo-random  number. 

Since  FORTRAN  is  a finite  state  language,  each  state 
can  lead  to  more  than  one  state.  Therefore  it  is  necessary 
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to  remember  all  the  nodes  that  were  visited  in  case  it 
becomes  necessary  to  back  up  to  another  point  in  the  graph. 
This  is  accomplished  through  associates  and  levels.  If  the 
graph  is  in  a certain  state,  the  parser  looks  at  the  next 
terminal  symbol  in  the  input  string.  If  that  terminal  symbol 
IS  a link  from  that  node  to  another  node,  that  link  is  se- 
lected. If  not,  an  associate  from  that  node  is  selected.  If 
there  is  no  associate,  the  level  is  selected  from  the  last 
previous  associate. 


The  syntax  graph  has  three  parts:  (1)  a FORTRAN  ex- 

pression graph  for  arithmetic  expressions,  (2)  a Boolean  ex- 
pression graph  for  logical  expressions,  and  (3)  an  I/O  list 
graph  for  I/O  lists.  These  three  parts  are  shown  in  Figures 
2-01,  2-02,  and  2-03.  An  example  to  illustrate  the  parsing 
of  an  arithmetic  expression  follows.  Consult  the  FORTRAN 
expression  graph  for  help  in  following  the  logic. 


The  expression  A+B*C  is  converted  to  the  string 

OPRAND  PLUS  OPRAND  STAR  OPRAND. 

This  string  is  traced  as  follows: 

29  93  133  208  452 

At  this  point  it  becomes  necessary  to  back  up  to  the  last 
previous  associate  and  take  the  level 
133  235 

back  up  to 

93  157 


back  up  to 

29  519  plus 

62  93  133 

back  up  to 

133  235 

back  up  to 

93  157  star 

133  208  452 

stop  state  found. 


sign  found 
208  452 


found 

string  empty 


The  parser  software  consists  of  the  following  subrou- 
t 1 nes : FORM , LVDLET , LVEX IT , LVFECH , LVFIND , LVGRN , LVNSRT , 

LVSETP, PARSE, PHONEY, PRNTS, RECOG, RECOV,SEMANT,SLEVEL,  and 
SSTOP.  LVDLET, LVFECH, LVFIND, LVGRN, LVNSRT,  and  LVSETP  are 
part  of  the  GIRS  memory  scheme.  The  remaining  parser  sub- 
routines are  originally  written  in  GIRL  and  processed  into 
FORTRAN.  The  explanation  of  the  parser  in  this  section  should 
not  be  considered  a comprehensive  description.  It  is  meant 
as  a general  description  so  as  to  aid  in  the  description  of  the 
subroutines  and  COMMON  blocks  which  follows.  A more  comprehen- 
sive description  of  the  parser  software  is  now  under  preparation 
at  the  Center  in  the  Computer  Sciences  Division. 
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FIGURE  2-01.  Arithmetic  Expression  Graph 


FIGURE  2-02.  Logical  Expression  Graph 


2.2  Detailed  Description.  All  program  units  of  the  AUDIT 
software  are  described  in  Sections  2.2.1  through  2.2.b9. 

After  the  main  program  the  program  units  are  listed  in 
alphabetical  order.  The  overall  function(s)  of  each  sub- 
program and  clarifying  remarks  are  described  in  the  openin;^ 
paragraph  for  each  subprogram  section.  Following  this 
opening  paragraph,  most  subprogram  sections  also  contain 
the  logical  flow  through  the  program  unit  listed  by  numbered 
steps.  All  data  elements  in  COMMON  are  described  in  Sections 
2.2.yu  through  2.2.122.  Tables,  arrays,  and  data  elements 
used  by  the  various  program  units  are  included. 

2 . 2 . 1_ M a i^n  _ P r og  r am  . 

1.  Read  the  options  card  which  contains  the  mode(s)  of 
operation,  input  device,  and  the  intrinsic  function 
parameter . 

2.  Initialize  global  variables  and  tables. 

3.  Read  the  Irrterface  Definition  file. 

4.  Initialize  non-global  variables  and  tables. 

d.  CALL  BUILD  to  assemble  the  next  source  statement. 

6.  Print  the  statement.  If  the  statement  is  a comrrrent  or 
a blank,  go  to  Step  5.  If  not,  increment  the  state- 
ment counter  and  CALL  CLASS  to  classify  the  statement. 

7.  CALL  STATNO  to  process  the  statement  number,  if  any. 

b.  Set  character  pointer  to  seven  and  save  classes  of 

current  and  preceding  statements. 

y.  If  it  is  the  first  statement  of  the  program  unit,  test 
that  it  is  a SUBROUTINE,  FUNCTION,  PROGRAM  (for  CDC 
only)  or  BLOCK  DATA  statement. 

ID.  If  it  is  not  the  first  statement  and  the  program  unit 
is  a BLOCK  DATA  subprogram,  check  that  the  statement 
is  an  EQUIVALENCE,  DATA,  DIMENSION,  COMMON,  or  type 
Statement . 

11.  Go  to  the  appropr  iate  statement  processor. 

12.  Check  all  specification  statements  for  proper  order. 

If  the  statement  is  a FUNCTION  statement,  reposition 

, the  character  pointer  ( if  FUNCTION  is  preceded  by  a 

type) . 

If  the  statement  is  an  assignment  statement,  change 
its  class  (if  it  is  a FUNCTION  defining  statement). 

13.  Write  out  the  statement. 

14.  If  it  is  the  first  statement  of  the  program  unit  and 
the  variable  precision  mode  has  been  selected,  generate 
type  statements  for  QICOMP  and  QIDPRE  (auxiliary 
variable  precision  subprograms  to  be  loaded  later)  on 
logical  unit  8. 

15.  If  END  statement  not  encountered  go  back  to  Step  5. 

16.  CALL  SUBCHK  to  check  the  arguments  (if  any)  of  the 
program  unit  against  the  Interface  Definition  file. 

17.  CALL  SYMTAB  to  display  the  symbol  table. 

CALL  GHT  to  update  the  global  reference  table. 


16 


CALL  COMCHK  to  check  COMMON  blocks  against  the 
Interface  Definition  file. 

CALL  LOOPCK  to  check  for  proper  nesting  of  DO 
loops  and  proper  nesting  of  control  throughout 
program  unit. 

CALL  FLOWCK  to  perform  flow  analysis,  if  desired. 

18.  If  there  are  more  program  units  to  be  processed, 
go  to  Step  4 . 

19.  CALL  GLOTAB  to  display  the  global  reference  table. 

20.  If  roll  call  mode  has  been  selected,  CALL  GENROL 
to  generate  the  main  roll  call  program. 

21.  Rewind  output  devices. 

2.2.2  SUBROUTINE  ARIF.  This  subroutine  processes  arithmetic 
IF  statements. 

1.  Verify  the  presence  of  the  keyword  IF  and  the 
presence  of  a left  parenthesis. 

2.  CALL  EXPR  to  code  and  analyze  the  expression. 

3.  CALL  PARSE  to  parse  the  expression. 

4.  CALL  FNCSTR  to  verify  function  references. 

5.  CALL  BLKSTR  to  Store  basic  blocks. 

6.  Set  NBRNCH,  the  counter  for  branches  out  of  the 
basic  block,  to  zero. 

7.  Fetch  the  three  statement  numbers  following  the 
expression,  store  them  in  the  statement  number 
table,  label  them  as  having  been  referenced,  and 
count  the  number  of  distinct  branches  out  of  the 
block. 

2.2.3  SUBROUTINE  ASGQTO.  This  subroutine  processes  assigned 
GO  TO  statements. 

1.  Check  keyword  spelling. 

2.  Fetch  the  GO  TO  variable,  test  that  it  is  a simple 
integer  variable,  and  store  it  in  the  basic  block 
table . 

3.  Initialize  the  branch  counter. 

4.  Fetch  the  next  statement  number  in  the  list,  store 
it  in  the  statement  number  table,  and  flag  it  as 
having  been  referenced. 

5.  Check  for  duplicates.  If  the  current  statement 
number  is  not  a duplicate,  store  it  in  the  basic 
block  table  and  increment  the  branch  counter. 

Process  the  rest  of  the  1 ist  and  set  the  new  block 
flag  to  1 . 

2.2.4  SUBROUTINE  ASSIGN.  This  subroutine  processes  ASSIGN 
statements . 


1.  Check  keyword  spelling. 


1.  Locate  the  statement  number  an<i  f 1 aq  it  as 
havinq  been  referenced. 

3.  Check  for  the  presence  of  the  keyword  TO. 

4.  Letch  the  assiqned  variable  and  check  that  it  is 
a simple  inteqer  variable. 

5.  Enter  the  index  to  the  variable  in  the  basic  block 
table. 

2.2.5  SUBROUTINE  AUXIQ.  This  subroutine  processes  REWIND, 

END  FILE,  and  BACKSPACE  commands  for  syntax  errors. 

2.2.6  INTEGER  FUNCTION  BITGET.  This  function  retrieves  a 
field  of  bits  from  a q iven  position  within  the  word  ILOC. 

IPOS  is  the  r iqhtmost  bit  position  (in  ILOC)  from  which  the 
field  will  be  retrieved.  IWIDTH  is  the  number  of  bits  in 
the  field. 

2.2.7  INTEGER  FUNCTION  BITPUT.  This  function  stores  a field 

of  bits  into  a q iven  position  within  the  word  ILOC.  Bits  are 
numbered  left  to  r iqht  startinq  with  1.  IVAL,  r iqht- 
justified  and  zero-filled,  is  the  word  which  contains  the 
field  to  be  stored.  IPOS  is  the  r iqhtmost  bit  position  (in 
ILOC)  into  which  the  field  will  be  stored. 

2.2.B  SUBROUTINE  BLKSTR.  This  subroutine  is  called  after 
an  expression  has  been  parsed.  It  stores  information  in  the 
basic  block  table. 

1.  Fetch  next  variable  in  the  expression. 

2.  If  variable  is  not  associated  with  a function 
reference,  store  it  as  referenced  and  qo  to  Step  1. 

3.  If  variable  is  associated  with  a function  reference, 
fetch  the  symbol  table  location  of  the  function, 
fetch  the  Interface  Definition  file  location  of  the 
function,  and  determine  which  of  the  function  arqu- 
m.ents  is  associatd  with  this  variable. 

4.  If  the  variable  associated  with  a function  reference 
is  a statement  function,  store  the  variable  as 
referenced  and  go  to  Step  1. 

5.  Fetch  the  I/O  status  (lOSTAT)  of  this  variable  from 
the  Interface  Definition  file.  If  IOSTAT=0,  the 
variable  is  output  and  is  stored  as  defined.  If 
I0STAT=1,  the  variable  is  both  input  and  output,  and 
is  stored  as  both  referenced  and  defined.  If 
I0STAT=2,  the  variable  is  input  and  is  stored  as 
referenced.  If  this  variable  appeared  in  an  arqument 
which  was  an  expression,  verify  that  the  arqument  is 
not  output  ( IOSTAT=0  or  1). 

2 . 2 . SUBROUTINE  BUILD.  This  subroutine  returns  a character 
strinq  of  lenqth  N in  array  A.  The  character  str  inq  consists 
of  the  next  statement  in  the  FORTRAN  proqram  unit  beinq 
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processed.  The  flaq  lERH  is  set  to  2 if  an  end-of-file 
condition  has  occurred.  If  there  are  more  continuation 
cards  than  permitted,  an  error  messaqe  is  printed. 

2 . 2 ._1_U  _ SJJBROUT I NL^J2AA  This  subroutine  packs  a string  of 
alphanumeric  characters  into  a single  word.  The  ISTR  array 
contains  the  characters  and  MSTR  is  the  number  of  characters. 
If  MSTR  is  greater  than  6,  the  string  is  too  long.  Each 
character  is  packed  into  ID  in  the  leftmost  available 
positions.  After  all  the  characters  have  been  packed,  ID  is 
filled  with  blanks. 

2_._2_._1 1_ HOUJI^IN^E  _C A I_._  This  subroutine  converts  a string 
of  alphanumeric  characters  to  an  integer.  The  ISTR  array 
contains  the  characters  and  MSTR  is  the  number  of  characters. 
If  MSTR  is  greater  than  10,  the  integer  is  too  large.  Each 
character  in  the  array  is  converted  to  its  integer  equivalent 
and  multiplied  by  the  proper  power  of  ten.  All  these  numbers 
are  added  up  and  stored  in  INTVAL.  The  size  of  INTVAL  is 
checked  against  the  maximum  value  (2**31-1). 

2.2.12  SUBROUTINE  CALL.  This  subroutine  processes  CALL 
statements . 

1.  Check  keyword  spelling. 

2.  Fetch  the  subroutine  name  and  check  it  for  validity. 

3.  Store  the  name  of  the  called  subroutine  in  the 
symbol  table  if  it  has  not  already  been  entered. 

4.  Perform  the  following  actions  if  the  subroutine 
doesn't  have  an  argument  list: 

a.  If  the  subroutine  is  not  in  the  Interface 
Definition  file,  store  it  there  temporarily. 
Store  this  temporary  location  in  the  svmbol 
table . 

b.  If  the  subroutine  is  in  the  Interface  Defi- 
nition file,  retrieve  its  location. 

c.  Verify  that  the  subroutine  has  no  arguments. 

5.  Perform  the  following  actions  if  the  subroutine 
has  an  argument  list: 

a.  Parse  the  statement 

b.  CALL  FNCSTR  to  Store  function  references. 

c.  CALL  BLKSTR  to  Store  basic  blocks  for  flow 
ana  1 y 5 i s . 

6.  If  the  variable  precision  mode  has  been  selected, 
CALL  CNVRT  to  insert  variable  precision  function 
ref  erences . 

7.  If  the  roll  call  mode  has  been  selected  and  this 
subroutine  is  a subroutine  module,  CALL  CALL2  to 
generate  a call  to  ROLCHK. 

2.2.13  SUBROUTINE  CALL2 . This  subroutine  is  called  by 
subroutines  CALL  (CALL  statement  processor)  and  INIT 
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(assignment  statement  processor)  when  the  roll  call  mode  has 
been  selected  and  when  the  subprogram  referenced  in  the  CALL 
oi  assignment  statement  appears  in  the  Interface  Definition 
file  as  a function  or  subroutine  module.  Given  a CALL  state- 
ment of  the  form 

CALL  SESPLl  (N,L,M) 

CALL2  transforms  the  statement  into 

CALL  ROLCHK  (IHS,  IHE,  IHS,  IHP,  IHL,  IHl). 

The  arguments  of  the  call  to  ROLCHK  are  generated  by  taking 
the  letters  or  numbers  of  the  called  subprogram  one  at  a 
t i"'e  . 

2.2.14  SUBROUTINE  CAR.  This  subroutine  converts  a string  of 
alphanumeric  characters  to  a real  or  double  precision  number. 
The  RN  array  contains  the  characters  and  NCHAR  is  the  number 
of  characters.  If  a real  number  has  more  than  20  digits,  or 
if  a double  precision  number  has  more  than  40  digits,  proc- 
essing is  aborted.  The  characters  are  packed  into  array  IHOL, 
r ight- j ust  i f led  and  b 1 ank- f i 1 1 ed  . The  DECODE  statement  con- 
verts the  characters  of  the  IHOL  array  to  a real  or  a double 
precision  number.  The  real  or  double  precision  number  is 
then  checked  against  the  maximum  and  minimum  values  (l.OE+38 
and  l.OE-38,  respectively). 

Note  that  this  subroutine  is  not  used  in  the  IBM  360 
or  UNIVAC  1108  versions  of  AUDIT,  since  in  those  versions 
the  magnitude  of  real,  double  precision,  or  complex  constants 
is  not  checked. 

2.2.15  SUBROUTINE  CHKLST.  This  subroutine  flags,  as  being 
initially  defined,  all  those  variables  which  have  been 
declared  in  COMMON  statements,  DATA  statements,  or  formal 
parameters  (which  are  designated  input),  or  which  have  been 
equivalenced  to  any  of  these.  This  subroutine  is  referenced 
by  subroutine  FLOWCK  for  the  flow  analysis  mode. 

2.2.16  SUBROUTINE  CLASS.  Given  the  character  string  A 
(which  contains  the  statement  currently  being  processed), 
this  subroutine  determines  the  type  of  statement.  There  are 
36  possible  types  of  statements  and  CLASS  sets  the  variable 
ITYP  to  the  appropriate  value  which  indicates  the  type  of 
statement.  The  codes  for  the  36  possible  types  of  statements 
are  given  in  Figure  2-04. 
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Statement  Type 

ITYP 

Ass  ignment 

1 

Assign 

2 

GO  TO 

3 

Ass  ig ned  GO  TO 

4 

Computed  GO  TO 

5 

Ar  i thmet ic  IF 

6 

CONTINUE 

7 

CALL 

8 

RETURN 

9 

STOP 

10 

READ 

11 

WRITE 

12 

REWIND 

13 

BACKSPACE 

14 

ENDFILE 

15 

Log  ical  IF 

16 

DO 

17 

END 

18 

INTEGER 

19 

REAL 

20 

DOUBLE  PRECISION 

21 

COMPLEX 

22 

LOGICAL 

23 

DIMENSION 

24 

COMMON 

25 

EQUIVALENCE 

26 

DATA 

27 

FORMAT 

28 

BLOCK  DATA 

29 

SUBROUTINE  ‘ 

30 

FUNCTION 

31 

PROGRAM 

32 

PAUSE 

33 

EXTERNAL 

34 

Statement  function 

35 

Unclass  if  ied 

36 

FIGURE  2-04.  Statement  Type  Codes 


CLASS  recognizes  all  statement  functions  initially  as 
assignment  statements.  They  are  subsequently  reclassified  as 
statement  functions  by  subroutine  INIT.  CLASS  makes  its 
classification  by  first  testing  to  see  whether  the  string  is 
a valid  assignment  statement.  If  it  is  not,  then  the  first 
few  characters  of  the  string  are  examined  to  determine  which 
of  the  FORTRAN  keywords  are  present.  The  appropriate  value 
of  ITYP  is  then  set. 
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2.2.17 SUBROUTINE  CMPARK.  This  subroutine  is  used  in  the 

I oil  call  mode  to  veri'fy'that  all  of  the  modules  referenced 
i)y  the  module  being  processed  weie  referenced  in  the  SESCOMP 
toll-call  mode.  CMPARE  requires  as  input  the  AUDIT  module 
list,  which  I es  ides  on  logical  unit  9,  and  the  roll  check 
module  list,  which  i es  ides  on  logical  unit  i.  CMPARE  checks 
that  all  modules  in  the  AUDIT  module  list  appear  on  the  roll 
check  module  lirt  for  all  valid  values  (0  to  -11)  of  the 
mode  index. 

^.^.18 SUBROUTINE  CNVRT.  This  subroutine  converts  coded 

output  fiom  subroutine  PARSE  into  BCD  (Binary  Coded  Decimal) 
and  returns  it  to  airay  A.  The  PARSE  output  is  the  result 
of  the  variable  precision  transformation  described  in 
Sect  ion  2.1.3. 

1.  Copy  the  left  side  of  an  assignment  statement  to 
the  output  ariay. 

2.  If  an  arithmetic  operator  in  the  input  string  is 
found,  copy  out  the  appropriate  operator. 

3.  If  a logical  operator  in  the  input  string  is  found, 
copy  the  appi opr  iate  operator  to  the  output  array. 

4.  If  the  codes  for  the  variable  precision  functions 
QlREAL,  QICOMP,  and  QlDPRE  are  found,  copy  out  the 
appropriate  function  name. 

b.  Process  the  code  for  a constant  or  variable  name. 

6.  Fetch  the  length  of  the  name. 

7.  Fetch  the  location  of  the  name  in  the  symbol  table. 

8.  Deal  with  constants. 

2.2.1^  SUBROUTINE  COM.  This  subroutine  processes  COMMON 
statements  by  checking  the  syntax  of  the  statements  and  by 
entering  the  declarative  information  in  the  statement  into 
the  symbol  table, 

1.  Check  keyword  spelling. 

2.  Add  each  COMMON  block  to  the  symbol  table. 

3.  Chain  together  the  variable  names  in  each  COMMON 
block  as  they  are  encountered.  The  COMMON  block 
name  points  to  the  first  vat  iable  in  the  block 
and  the  last  variable  in  the  block.  The  last 
variable  in  a chain  contains  a pointer  to  the 
beginning  of  the  chain.  Each  variable  in  the 
chain  points  back  to  the  COMMON  block  name. 

4.  Maintain  counts  of  the  number  of  COMMON  blocks  and 
their  lengths. 

5.  Test  each  block  name  and  each  variable  name  to 
insure  that  it  is  in  the  proper  class,  i.e.,  that 
it  is  not  also  the  name  of  a function. 

2.2.2U  SUBROUTINE  COMCHK.  This  subroutine  is  referenced 
after  all  statements  of  the  program  unit  being  analyzed  have 
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been  processed.  It  checks  the  validity  of  all  COMMON  blocks 
that  appeared  in  the  proqram  unit. 

1.  Get  next  COMMON  block  from  the  symbol  table. 

2.  Fetch  the  cateyory  and  size  of  COMMON  block  from 
the  Interface  Definition  file  and  check  the  size 
(for  Category  1).  The  sizes  of  Category  2 and  3 
blocks  are  checked  for  consistency  if  they  appear 
in  other  program  units  being  analyzed. 

3.  Fetch  next  variable  in  COMMON  block,  along  with 
its  type  and  size  (if  it  is  an  array). 

4.  If  variable  is  complex  or  double  precision,  verify 
that  it  begins  on  an  even  word  within  the  COMMON 
block. 

5.  If  this  is  a BLOCK  DATA  subprogram,  verify  that  the 
variables  are  in  their  prescribed  order  (real, 
integer,  double  precision,  complex,  and  logical). 

6.  If  this  is  a Category  2 COMMON  block,  verify  that 
it  is  grouped  by  type. 

7.  If  this  is  a Category  2 or  3 COMMON  block,  verify 
that  all  the  variables  are  used. 

8.  If  this  is  a Category  1 COMMON  block,  check  the 
variable  types  against  the  Interface  Definition 
file. 

9.  Check  for  the  existence  of  COMMON  block  SESCOM  and 
check  for  its  prescribed  variables. 

2.2.21  SUBROUTINE  COMEXT.  This  subroutine  is  referenced  by 
.subroutine  EQUIV  (EQUIVALENCE  statement  processor)  to  determine 
whether  an  EQUIVALENCE  statement  extends  COMMON  and  whether 
a double  precision  or  complex  variable  begins  on  an  even 
location  within  COMMON. 

1.  Fetch  the  location  in  the  symbol  table  of  the  COMMON 
block  which  contains  the  equLvalenced  variable. 

2.  Fetch  the  location  of  the  last  variable  in  the  block. 

3.  Fetch  the  size  of  the  block. 

4.  Calculate  the  total  number  of  storage  units  which 
precede  the  equivalenced  variable  in  its  COMMON  block. 

5.  Fetch  the  next  variable  and,  if  it  is  equivalenced, 
transfer  out  of  the  loop  to  statement  number  25. 

6.  If  the  variable  is  dimensioned,  go  to  statement 
number  10.  Otherwise  increment  the  storage  unit 
counter  and  continue  the  loop. 

7.  If  the  variable  is  dimensioned,  compute  the  number  of 
storage  units  required  from  the  dimensions  of  the 
array. 

8.  From  the  above  result,  calculate  the  number  of 
storage  units  in  the  COMMON  block  which  follow  the 
equivalenced  variable. 

9.  If  the  variable  is  double  precision  or  complex,  test 
that  it  begins  on  an  even  location. 
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10.  Test  whether  COMMON  is  extended. 

11.  Fetch  the  offset  (see  SUBROUTINE  EQUIV)  of  the  equiv- 
alenced  variable  in  the  COMMON  block. 

12.  Fetch  the  offset  of  each  variable  in  the  equivalence 
chain,  calculate  the  first  and  last  storage  unit 
locations  occupied  by  the  variable,  and  check  whether 
these  locations  lie  within  the  storage  area  occupied 
by  the  COMMON  block. 

2.2.22  SUBROUTINE  COMSCH . Given  the  COMMON  block  name  stored 
in  NXTID,  this  subroutine  sets  ISRCH(3)  equal  to  1 if  the  name 
is  found  in  the  symbol  table  and  0 if  it  is  not. 

2.2.23  SUBROUTINE  CTGOTO.  This  subroutine  processes  computed 
GO  TO  statements. 

1.  Check  keyword  spelling  and  for  the  presence  of  a left 
parenthes  is  . 

2.  Reserve  a space  in  the  basic  block  table  for  the  GO 
TO  variable.  JBLOCK  is  used  to  store  the  index  to 
that  space. 

3.  Initialize  the  branch  counter. 

4.  Procure  and  check  the  statement  numbers  in  the  state- 
ment number  table. 

5.  Set  the  flag  in  the  statement  number  table  which 
indicates  that  the  statement  number  has  been  refer- 
enced . 

6.  If  the  statement  number  has  occurred  previously  in 
this  statement,  go  to  statement  number  17.  Otherwise 
store  the  statement  number  in  the  basic  block  table 
and  increment  the  branch  counter. 

7.  After  all  the  statement  numbers  have  been  processed, 
fetch  the  GO  TO  variable  and  test  that  it  is  a simple 
integer  var  iable . 

8.  Store  the  index  of  the  variable  in  the  basic  block 
table,  set  the  new  basic  block  flag  to  1,  and  return 
to  the  referencing  program. 

2.2.24  SUBROUTINE  DATA.  This  subroutine  processes  DATA 
statements . 

1.  Check  keyword  spelling  and  perform  some  initiali- 
zat  ion  . 

2.  Fetch  the  next  variable  name  and  enter  it  in  the 
symbol  table  if  it  is  not  already  there. 

3.  Test  the  variable  for  a previous  appearance  in  a 
DATA  statement. 

4.  Test  the  variable  to  determine  if  it  is  a formal 
parameter. 

5.  Determine  whether  the  variable  is  in  COMMON.  Issue 
an  error  message  if  the  variable  is  in  blank  COMMON 
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or  if  the  variable  is  in  labeled  COMMON  and  this 
is  not  a BLOCK  DATA  subprogram. 

6.  Test  for  a left  parenthesis  occurring  next  in  the 
statement,  in  which  case  the  variable  name  preceding 
the  left  parenthesis  must  be  the  name  of  an  array. 

7.  If  the  variable  is  the  name  of  an  array,  check  the 
subscripts  against  the  dimensions  given  in  the 
DIMENSION  statement  for  the  variable  in  question. 

8.  If  a dimensioned  variable  is  used  without  a subscript, 
calculate  the  size  of  the  array. 

9.  Begin  processing  the  constant  list.  To  detect  any 
discrepancies  between  the  number  of  variables  in  the 
variables  list  and  the  number  of  constants  in  the 
constant  list,  two  counters  (LSTlSZ  and  LST2SZ)  are 
used  to  keep  the  respective  counts.  Initialize  the 
repeat  counter . 

10.  Fetch  the  next  element  and,  if  it  is  a Hollerith 
string,  go  to  statement  number  47.  If  it  is  not  a 
Hollerith  string  and  if  the  element  is  not  an  integer, 
go  to  statement  number  45. 

11.  The  element  is  either  an  integer  or  a repeat  count 
for  a following  element.  If  it  is  a repeat  count, 
convert  it  to  binary  and  store  it  in  NRPEAT. 

12.  Check  whether  a sign  precedes  the  constant. 

13.  Test  the  constant  to  see  if  it  is  real,  integer, 
complex,  Hollerith,  or  logical. 

14.  Increment  the  constant  list  size  counter.  The  next 
element  in  the  string  being  processed  should  be  either 
a comma  or  a slash.  If  it  is  a comma,  go  to  statement 
number  40  to  get  the  next  element.  If  it  is  a slash, 
compare  the  two  list  size  counters  and,  if  they  are 
not  equal,  print  an  error  message.  If  the  element 
following  the  slash  is  a comma,  go  to  statement 
number  8 to  process  another  list.  If  it  is  not  a 
comma,  a blank  signifies  the  end  of  the  statement. 

2.2.25  SUBROUTINE  DESCRP.  Given  the  starting  point  IDESST 
in  the  string  A,  this  subroutine  sets  the  variables  IDES  to  1 
if  the  substring  which  follows  is  a valid  format  field 
descriptor  and  0 if  it  is  not.  A valid  format  field  descriptor 
is  one  of  the  following: 

’# 

vt  srFw.d 

srEw.d 

••  srGw.d 

^ srDw.d 

< r Iw 

» rLw 

r Aw 

nHhj  h^.  . . • h 
nX 
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where  w and  n are  non-zero  integer  constants,  d is  an  integer- 
constant,  I is  an  optional  non-zero  integer  constant,  and  s 
is  optional  and  represents  a scale  factor  designator  of  the 
form  mP,  where  m is  an  integer  constant  or  minus  followed  by 
an  integer  constant. 

2.2.26  SUBROUTINE  DIMEN.  This  subroutine  processes  DIMENSION 

statements  by  checking  keyword  spelling  and  then  adding  to  the 
symbol  table  the  dimension  information  for  each  variable  in  the 
list.  Errors  diagnosed  by  this  subroutine  include  exceeding 
allowable  array  bounds,  illegal  use  of  variable  dimensions, 
illegal  use  of  subprogram  names,  dimensioning  previously  dimen- 
sioned variables,  and  other  illegal  uses  of  dimensioned  varia- 
bles . 

2.2.27  SUBROUTINE  DO.  This  subroutine  processes  DO  state- 
ments. 

1.  Check  keyword  spelling. 

2.  Fetch  the  statement  number  of  the  terminal  statement, 
enter  it  in  the  statement  number  table,  and  flag  it 
as  having  been  referenced. 

3.  Store  the  terminal  statement  number  index  and  the  DO 
loop  number  in  the  DO  stack. 

4.  Fetch  the  induction  variable  name,  store  it  in  the 
symbol  table,  and  check  that  it  is  a simple  integer 
var  iable . 

5.  Check  for  the  presence  of  the  equals  sign. 

6.  Enter  the  induction  variable  name  in  the  basic  block 
table. 

7.  Store  the  induction  variable  name  in  the  DO  stack. 

rf.  Make  a detailed  check  of  the  three  DO  parameters 

defining  the  initial  value,  the  final  value,  and  the 
increment  of  the  induction  variable.  A "998"  flag 
is  inserted  in  the  basic  block  to  show  that  control 
passes  to  the  next  basic  block  (see  FUNCTION  NXTBLK). 

2.2.28  SUBROUTINE  EQUIV.  This  subroutine  processes  EQUIVA- 
LENCE statements  by  checking  them  for  proper  syntax  and  by 
analyzing  the  declarative  information  in  the  statements  for 
consistency  and  confoimance  with  the  Standard.  Although  the 
function  perfotmed  by  EQUIV  is  conceptually  simple,  the  imple- 
mentation is  sufficiently  complex  to  warrant  the  following 
detailed  explanation. 

In  an  EQUIVALENCE  statement  of  the  form  EQUIVALENCE 
(A,B),  (C,D),  the  variables  within  parentheses  are  said  to  be 
in  equivalence  groups.  Simple  (undimensioned)  variables  in 
an  equivalence  group  occupy  the  same  storage  location.  With- 
in the  symbol  table,  space  is  set  aside  to  permit  the  linking 
together  in  a chain  of  all  the  variables  in  an  equivalence 
group.  An  additional  field  in  the  symbol  table  entry,  called 
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the  offset  field,  is  piovided  to  oe  used  when  one  or  more  of 
the  vai  tables  in  the  equivalence  chain  is  dimensioned.  For 
example,  if  we  had  the  statements  DIMENSION  B(10,10),  C(10,10) 
and  EQUIVALENCE  (A,B(1),  C(2)),  then  A and  B would  have  an 
offset  of  zeio  and  C would  have  an  offset  of  -1  to  indicate 
that  the  ai i ay  C starts  one  location  before  the  variable  A 
and  the  array  B.  If  the  statement  EQUIVALENCE  (B(2),D)  is 
included  with  the  other  two  statements,  then  since  B(l)  has 
an  offset  of  zero,  B{2)  will  have  an  address  of  1 relative 
to  the  rest  of  the  equivalence  group.  Thus,  D would  have  an 
offset  of  1 . 

Errors  diagnosed  by  EQUIV  include: 

a)  Directly  or  indirectly  causing  two  different 
elements  of  the  same  array  to  be  equivalenced 
to  each  other  . 

b)  Directly  or  indirectly  introducing  gaps  in  the 
storage  map  of  the  array. 

c)  Extending  COMMON  in  either  direction. 

1.  Check  keyword  spelling. 

2.  Test  for  the  left  parenthesis  which  starts  an  equiv- 
alence group. 

3.  Perform  some  initialization,  including  setting  the 
base  offset  value  to  zero,  and  begin  processing  an 
equivalence  group.  CALL  GNLE  to  get  the  next  lan- 
guage element  in  the  statement.  Test  the  name  to 
determine  whether  the  language  element  was  an 
identifier,  and  store  the  name  in  the  symbol  table, 
if  it  is  not  already  present. 

4.  Process  subscripted  variables. 

5.  Compute  the  offset  for  the  variable. 

6.  Process  variables  which  have  not  previously  appeared 
in  an  EQUIVALENCE  statement.  Set  the  "has  been 
equivalenced"  flag  in  the  symbol  table  entry.  Test 
to  see  if  this  is  the  first  element  in  a chain.  If 
not,  store  the  location  of  this  element  in  the 
symbol  table  entry  of  the  previous  element  in  the 
chain.  In  any  case  store  the  offset  for  this 
element  in  the  symbol  table  entry  for  that  element. 

7.  If  the  variable  has  previously  appeared  in  an 
EQUIVALENCE  Statement,  merge  the  two  equivalence 
chains  and  recalculate  the  offsets  of  the  merged 
cha  in . 

b.  Merge  the  chain  and  adjust  the  offsets  in  the 
merged  chain. 

y.  Check  whether  two  variables  in  COMMON  have  been 

equivalenced,  whether  COMMON  has  been  extended,  and 
whether  syntax  errors  have  been  made  in  the  EQUIV- 
ALENCE statement. 


^.1.2^  SUBROUTINK ERROR . This  subroutine  prints  an  appro- 

prTate  error  message  when  a program  unit  of  the  AUDIT  soft- 
ware finds  an  error  in  the  program  unit  being  analyzed. 

2.2.JU  SUBROUTINE  EXPR.  Given  the  starting  location  of  a 
character  string  representing  a FORTRAN  expression  or  an  I/O 
list,  this  subroutine  encodes  the  expression  for  later 
process  i ng  . 

The  character  string  is  examined  and  output  array  STR  is 
generated.  Figure  2-05  shows  the  encoding  for  operators. 


Character  Code 


+ -1 

-2 

/ -3 

( -4 

) -5 

, -6 

* -7 

**  -8 

.LT.  -9 

.LE.  -10 

.GT.  -11 

.GE.  -12 

.EQ.  -13 

.NE.  -14 

.OR.  -15 

.AND.  -16 

.NOT.  -17 

= -18 


FIGURE  2-05.  Encoding  Operator  Codes 


Var  iable  names  are  encoded  as 
I + 104  A + 1u5  b + 1o6  M 

where  I is  the  starting  location  of  the  variable  name  in  the 
character  str  ing  , 


A = 

0 

if 

the 

var  iable 

is 

real 

= 

1 

if 

the 

var  iable 

is 

complex 

= 

2 

if 

the 

var  iable 

i s 

double  precision 

= 

3 

if 

the 

var  iable 

is 

integer 

= 

4 

if 

the 

var  iable 

is 

1 og  ical 

B = 

U 

it 

the 

var  iable 

is 

simple 

= 

1 

if 

the 

var  iable 

has 

one  subscr  ipt 

= 

2 

if 

the 

var  iable 

has 

two  subscr ipts 
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= 3 if  the  variable  has  three  subscripts 
= 4 if  the  substring  is  a constant 
= 5 if  the  name  is  a function  reference 
M is  the  length  of  the  substring. 

The  number  of  entries  in  the  encoded  array  is  stored  in 

NSTK . 

1.  Test  for  an  end  of  the  expression,  which  is  one  of 
the  following; 

a.  no  more  characters  in  string 

b.  equals  sign  in  an  assignment  statement 

c.  right  parenthesis  in  a logical  IF  statement. 

2.  If  a terminal  symbol  is  not  encountered  encode 
character  as  indicated  in  Figure  2-L)5. 

3.  If  character  is  a name  followed  by  a left  parenthesis 
determine  whether  it  is  a function  reference  or  an 
array  element  and  encode  it  accordingly.  If  a func- 
tion is  a basic  external  or  intrinsic  function,  get 
its  type  from  the  Interface  Definition  file. 

4.  If  function  name  is  not  followed  by  a left  paren- 
thesis, verify  that  the  variable  is  the  function  name 
within  the  function-defining  subprogram  (see  case  B 
of  SUBROUTINE  INIT) . 


2.2.31  SUBROUTINE  EXPRCK.  After  an  assignment  statement  has 
been  processed,  this  subroutine  is  called  to  see  if  the 
assignment  is  legal.  An  assignment  statement  is  of  the  form 
V=E,  where  V is  a variable  name  and  E is  an  expression.  Legal 
assignments  are  listed  in  Figure  2-U6. 


V 

E 

Integer 

Integer 

I nteger 

Rea  1 

I nteger 

Doubl e Precision 

Real 

Integer 

Real 

Real 

Rea  1 

Double  Precision 

Double  Precis  ion 

Double  Precis  ion 

Double  Precis  ion 

I nteger 

Complex 

Complex 

Log  ical 

Log  ical 

FIGURE  2-U6.  Legal 

Assignment  Rules 

2.2.32  SUBROUTINE  FLOWCK . This  subroutine  examines  all 
possible  paths  through  a given  program  unit  to  determine 
whether  or  not  all  the  variables  required  for  the  computation 
at  a given  point  in  the  subprogram  are  properly  defined  in  the 
sense  that  SESCOMPSPEC3  requires.  FLOwCK  is  used  during  the 
flow  analysis  mode. 
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Tho  appi oach  adopted  is  based  on  the  work  of 
Ramamooi t hy  ' The  method  used  is  to  qeneiate  one  by  one  all 
the  complete  paths  in  the  piogtam  unit.  Aftei  each  path  is 
qeneiated,  the  flow  of  vai  iable  definition  and  undefinition 
is  t t aced  out  alonq  that  path.  A complete  path  is  defined  to 
be  a path  which  commences  at  the  beqinninq  of  the  pioqram  unit, 
teiminates  in  a STOP  oi  RETURN  statement,  and  in  which  no 
statement  number  appeal s mote  than  twice.  Strictly  speaking, 
this  definition  excludes  some  possible  paths  from  consid- 
erations f)Ut  most  practical  programs  are  fully  analyzed.  Two 
data  structures  provide  the  information  required  for  this 
analysis:  IBLOCK  and  ISTACK,  which  are  fully  described  in 

Sections  2 . H . g 1 and  2.2.92,  respectively. 

Br  lefly,  however,  IBLOCK  is  an  array  of  basic  blocks,  a 
tauic  block  being  a group  of  statements  in  the  source  program 
which  physically  appear  together  in  the  program,  which  are 
located  irv  the  same  DO  loop,  and  which  are  executed  together 
(See  Section  2.1.4).  ISTACK  is  an  array  which,  for  each  DO 
statement,  contains  the  statement  number  of  the  terminal  state- 
ment, the  index  in  the  symbol  table  of  the  induction  vat  iable, 
ana  the  index  in  the  ISTACK  array  of  the  DO  in  which  this  DO 
is  nested.  Some  of  the  intermediate  data  structures  used  by 
FLOWCK  are: 

a.  FLWLST  - This  list  contains  the  indices  of  the 
basic  blocks  which  are  on  the  path  currently  being 
considered.  If  the  index  in  FLWLST  is  negative, 
there  remain  some  branches  in  the  block  which  have 
not  yet  been  examined. 

b.  ISTCK  - This  list  contains  the  branch  list  for  the 
basic  block  being  processed.  The  last  branch  is 
flagged  as  being  negative. 

In  addition,  a flag  in  the  symbol  table  is  used  to  maintain 
the  status  of  each  variable,  i.e.,  whether  it  is  undefined, 
defined,  an  induction  variable,  or  assigned. 

1.  If  there  are  structural  syntax  errors  in  the  program 
unit,  do  not  perform  the  flow  analysis  and  issue  a 
message . 

2.  CALL  CHKLST  to  flag,  as  being  initially  defined,  all 
variables  in  COMMON  and  DATA  statements,  as  well  as 
all  formal  parameters  which  are  designated  as  logical 
input.  Also  flag,  as  being  initially  defined,  any 
variable  which  is  equivalenced  to  any  of  the  above. 

J.  Initialize  symbol  table  for  next  path  and  initialize 
current  block  at  1 . 

4.  Generate  the  next  path  (Steps  5-10). 

5.  If  path  is  non-empty,  count  the  number  of  occurrences 
of  the  current  basic  block  in  the  path.  If  greater 
than  the  limit  (2  for  full  flow  analysis  and  1 for 
moderate  flow  analysis),  go  to  Step  23  and  attempt  to 
generate  a new  path. 
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b.  It  path  is  okay  so  far,  add  the  current  basic  block 
to  the  path  (FLWI.ST). 

7.  Get  the  next  basic  block  which  this  block  branches 
to  and  make  it  the  current  block. 

8.  If  ttiere  is  more  than  one  branch  from  the  block, 

set  the  block  index  to  negative  in  FLa'LST  to  indicate 
that  there  are  more  branches  to  consider, 
y.  Store  the  last  branch  in  the  block  in  ISTCK  and  flag 

it  as  negative  to  indicate  that  it  is  the  last  branch. 
Store  all  other  branches  as  positive. 

10.  If  it  is  not  the  end  of  the  path,  go  to  Step  5. 

LI.  Path  has  been  generated. 

12.  Increment  path  counter. 

IJ.  Get  the  next  block  in  path  and  its  statement  label 
and  DO  loop. 

14.  Analyze  all  variables  in  the  block.  Get  variable 
class  from  IBLOCK  array  (see  COMMON  block  BASBLK). 

1 0 . If  variable  is  defined,  check  that  the  variable  is 

not  a DO  parameter,  a DO  index,  or  a variable  dimen- 
sion. If  variable  is  equ  ival enced , set  all  equiva- 
lenced  variables  of  the  same  type  to  defined  and  set 
all  equivalenced  variables  of  different  type  to 
undefined.  Set  status  flag  to  1 if  variable  is 
de f i ned  . 

16.  If  variable  is  referenced,  check  that  the  variable  is 
defined  and  not  assigned. 

17.  If  variable  is  a DO  index,  check  that  the  variable  is 
not  a variable  dimension  and  is  not  currently  a DO 
index.  Set  status  flag  to  2 for  DO  index  variable. 

18.  If  variable  is  assigned,  check  that  the  variable  is 
not  a variable  dimension  nor  a DO  index.  Set  status 
flag  to  i for  assigned  variable. 

ly.  If  variable  is  referenced  by  an  assigned  GO  TO,  check 
that  the  variable  is  assigned. 

20.  If  variable  is  made  undefined,  set  status  flag  to  U. 

21.  If  variable  is  a DO  parameter,  check  that  the  variable 
is  defined  and  not  assigned.  Set  status  flag  to  4 

for  DO  parameter  variable. 

22.  If  there  are  more  variables,  go  to  Step  14. 

2i.  At  this  point  path  processing  is  complete.  Path  has 
either  been  analyzed  or  rejected. 

24.  Begin  to  generate  the  next  path. 

25.  Starting  at  the  bottom  of  the  flow  path,  find  the 
first  negative  index  indicating  a branch  point.  If 
none  remain,  go  to  Step  28. 

26.  Fetch  the  branch  from  the  top  of  the  stack.  If  this 
branch  is  negative,  indicating  that  it  is  the  last 
branch  from  this  point,  reset  the  flow  path  index 

to  pos  i t ive . 

27.  Reset  the  stack  counter  and  current  path  index  and  go 
to  Step  4 to  complete  generation  of  this  path. 
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28.  All  paths  have  been  processed.  Check  that  each 
statement  label  appears  in  a path. 

2.2.JJ  SUBROUTINE  FNCSTR.  This  subroutine  is  called  after 
parsin']  a CALL  or  assignment  statement  to  check  all  function 
references  a'jainst  the  Interface  Definition  file. 

1.  It  there  are  no  function  references,  RETURN. 

2.  Fetch  next  function  reference  from  FNCLOC. 

i.  If  Lt  is  a statement  function,  call  STFNC  to  process 
the  statement  . 

4.  Fetch  number  of  arguments  and  function  type. 

5.  If  function  has  previously  appeared,  go  to  Step  7. 

6.  Search  the  Interface  Definition  file  for  function 
name . 

a.  If  found,  store  file  location  in  symbol  table 
and  go  to  Step  8. 

b.  If  not  found,  issue  diagnostic  and  store  name 
in  the  temporary  Interface  Definition  file. 

Store  file  location  in  the  symbol  table.  Store 
function  type,  number  of  arguments,  argument 
type,  dimensionality,  and  I/O  status  in  temporary 
Interface  Definition  file. 

7.  Fetch  Interface  Definition  file  location  of  function. 

8.  Fetch  number  of  arguments  from  Interface  Definition 
file  and  check  for  correctness. 

y.  Compare  type,  dimensionality,  and  I/O  status  of  each 
argument  against  the  Interface  Definition  file. 

2.2.34  SUBROUTINE  FORM.  This  subroutine  creates  the  format 
used  to  print  the  error  diagnostic  issued  by  SUBROUTINE  PRNTS. 

2.2.35  SUBROUTINE  FORMED.  Given  the  character  string  D 
generated  by  SUBROUTINE  GNLE,  this  subroutine  processes 
language  elements.  Note  that  SUBROUTINE  CAR  is  not  referenced 
for  the  IBM  360  or  UNIVAC  1108  versions  of  AUDIT. 

1.  CALL  CAA  to  process  identifiers. 

2.  Compute  size  of  Hollerith  string.  Adjust  the 
character  pointer  JPTR.  Check  validity  of  each 
character  in  the  string. 

3.  CALL  CAR  to  process  real  numbers  (for  CDC  only). 

4.  CALL  CAI  to  process  integer  numbers. 

5.  For  complex  numbers,  CALL  CAR  to  process  both  real 
numbers  which  comprise  the  complex  number  (for  CDC 
only)  . 

6.  Do  not  process  operators  and  logical  constants. 

2.2.36  SUBROUTINE  FRMAT.  Given  a character  string  A,  this 

subroutine  determines  whether  or  not  it  is  a valid  SESCOMP 

FORMAT  statement,  i.e.,  whether  it  has  the  form  (q[tj  Z|t,ZT.. 

t , z , t q , where  each  q is  a series  of  slashes  or  is 
rr  1 n-  1 n ^ 2 ^ 
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empty,  each  t is  a field  desct  iptor  or  group  of  field 
descriptors,  each  z is  a field  separator,  and  n may  be  zero. 
FKMAT  sets  IFHMT  to  1 if  the  FORMAT  Statement  is  valid  and 
0 if  It  is  not.  FKMAT  calls  subroutines  GROUP,  SKPAR,  and 
DFSCRP  to  help  process  the  FORMAT  statement. 

. il  SUBROUTINE  GENROL.  When  the  roll  call  mode  has  been 
selected,  this  subroutine  generates  a main  program  which  is 
then  compiled  by  the  FORTRAN  compiler  along  with  the  program 
unit  (should  be  a root  program  unit  of  a module)  being  ana- 
lyzed. This  main  program  then  calls  the  module  root  program 
unit  in  the  SESCOMP  roll-call  mode  for  all  permissable  (and 
one  error  value)  values  of  the  mode  index.  The  basic  form  of 
the  proqtam  generated  by  GENROL  is  as  follows: 

PROGRAM  ROLCAL  ( OUTPUT , TAPE6=0UTPUT , TAPE 3 , TAPE9 , 
*TAPE1U ,TAPE11 ,TAPE12 ,TAPE1 3 ,TAPE14 ,TAPE1 5 ) 

COMMON/ NAME 0/ I XO ( NU ) 

COMMON/NAMEl/IXl ( Ni ) 

COMMON/NAME2/IX2 ( N2 ) 


COMMON/SESCOM/IX j (Nj ) 


COMMON/NAMEn/ IXn ( Nn ) 
J = 1 

MODE=m 

DO  10  1=1,13 
J=J-1 

DO  1000  K=1,N0 
IX0(K)=1 
1000  CONTINUE 

DO  1001  K=1,N1 

j IX1(K)=1 

I 1001  CONTINUE 


DO  lOOj  K=l,Nj 
IX] (K)=l 
lOOj  CONTINUE 

IX](17)=10 
IXj (20)=11 
IXj(23)=12 


DO  lOOn  K=l,Nn 
IXn( K) =1 
lOOn  CONTINUE 

CALL  SUBR(A1,A2,A3, . . . . ,An,J) 
IF(MODE.EQ.3)  GO  TO  5 
CALL  MODID(J) 
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A 


5 ENDf-'ILK  J 
lU  CONFINUK 

CALL  CMPARE 
REWIND  13 
REWIND  14 
REWIND  15 
STOP 
END 

The  followiny  items  pertain  to  ROLCAL: 

NAME i is  the  name  o£  the  i^ ’COMMON  block  of  the 
module  root  program  unit. 

IX  i is  a dummy  COMMON  block  element  name 
Ni  is  the  length  of  the  i ’ ’COMMON  block. 

SESCOM  is  the  mandatory  labeled  COMMON  block 
(N]  should  be  equal  to  25) 

m is  one  of  two  options  for  the  roll  call  mode. 

If  m=2  most  roll  call  actions  are  performed  by 
the  program  unit.  If  m=3  most  roll  call  actions 
are  performed  by  the  SESCOMP  roll  call  utility 
module  ROLCOL. 

SUBR  is  the  name  of  the  program  unit  being  ana- 
lyzed . 

MODID  is  an  auxiliary  subroutine  called  to  print 
out  what  was  written  on  each  output  device  by  SUBR. 
CMPARE  is  an  auxiliary  subroutine  called  to  ver  ify 
that  all  of  the  mooules  referenced  by  SUBR  were 
referenced  in  the  SESCOMP  roll  call  mode. 

The  PROGRAM  statement  is  only  uned  for  the  CDC 
version  of  AUDIT.  This  statement  is  omitted  for 
the  IBM  360  and  UNIVAC  IlOB  versions. 

The  logic  for  SUBROUTINE  GENROL  follows: 

1.  Perform  initialization,  including  creation  of  COMMON 
block  number  s . 

2.  Generate  the  PROGRAM  statement  (for  CDC  version  only). 

3.  Generate  the  COMMON  statements  for  each  COMMON  block. 

4.  Generate  the  top  of  the  loop  for  stepping  through  the 
values  of  the  mode  index. 

5.  Generate  the  code  to  set  each  COMMON  block  element  to 

1 . 

6.  Generate  the  code  to  define  the  SESCOM  output  devices. 

7.  Generate  the  call  to  the  program  unit  being  analyzed, 
making  sure  that  the  proper  number  of  arguments  are 
incl uded  . 

8.  Generate  the  remainder  of  the  program. 

2.2.38 SUBROUTINE  GLOTAB.  This  subroutine  displays  the  global 

refer  ence  table . 

1.  Display  heading 
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z.  Fetch  exteinal  references  from  the  external 

tefeience  list.  Fetch  class  of  each  external 
(efeience  f t om  the  Interface  Definition  file  and 
display  all  exteinals. 

i.  Fetch  COMMON  block  names  from  the  COMMON  block  list. 
Fetch  size  and  class  of  each  COMMON  block  f i om  the 
Intel  face  Definition  file  and  display  all  COMMON 
blocks . 

4.  Fetch  the  name  of  each  program  unit  being  analyzed 
fiom  the  subpiogtarn  list.  Fetch  the  class  of  each 
piogiam  unit  from  the  Interface  Definition  file  and 
display  all  progiam  units. 


2 . 2 . S')  SUBROUTINE  GNLE.  Given  the  chat  acter  string  A and  the 
pointer  JPTR  into  the  string,  this  subroutine  finds  the  next 
language  element,  stores  it,  and  classifies  it.  The  element 
is  stored  in  array  D,  and  M is  set  to  its  length.  The  pointer 
JPTR  is  set  to  the  first  location  in  A following  the  element. 
The  var  iable  JTYP  is  set  according  to  Figure  2-07. 


JTYP 

0 

1 

2 

J 

4 

'3 

6 

7 

« 


Language  Element 
Blank 

Arithmetic  operator 
Ident  if  ier 
Hoi ler  ith  string 
Real  number 
Integer  number 
Complex  number 

Logical  constant  or  operator 
or  relational  operator 
Inval  id 


FIGURE  2-07.  Language  Element  Codes 


2.2.40  SUBROUTINE  GOTO.  This  subroutine  processes  GO  TO 
statements . 

1.  Check  keyword  spelling. 

2.  Check  the  statement  number. 

J.  Flag  the  statement  number  in  the  statement  number 
table  as  having  been  referenced. 

4.  Process  the  basic  block  by  storing  the  statement 
number  in  the  basic  block,  setting  NBRNCH,  the 
counter  for  the  number  of  branches  out  of  the  block, 
to  1,  and  setting  NB,  the  "new  block"  parameter,  to  1. 

2.2.41  SUBROUTINE  GROUP.  Given  IGRST  and  IGRND,  the  beginning 

and  end  of  a character  string,  this  subroutine  sets  IGRP  to  1 
if  that  sti  ing  is  a valid  group  of  format  field  descriptors  and 
U if  it  is  not. 
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SUBROUTINE  GRT.  This  subroutine  is  called  after  each 
pioqram  unit  has  been  ptocessed.  It  maintains  a composite 
list  of  names  (global  reference  table)  of  subprograms  and 
COMMON  blocks  t efei enced  by  each  of  the  program  units  being 
ana  1 y zed  . 

1.  Fetch  the  name  of  the  first  subprogram  in  the  input 
table.  If  there  are  no  more  entries,  go  to  Step  5 
to  process  COMMON  block  names. 

2.  If  the  name  is  a statement  function,  bypass  that  name 
and  get  the  next  name. 

3.  Search  the  external  reference  table  to  see  if  the 
name  is  already  stored.  If  not,  store  the  Interface 
Definition  file  location  of  the  name  in  the  external 
reference  table. 

4.  If  operating  under  the  roll  call  mode,  and  if  the 
subprogram  is  a function  or  subroutine  module,  write 
the  name  on  logical  unit  9 to  be  used  later  dur  ing 
roll  call  check . 

5.  Process  COMMON  block  information. 

6.  Fetch  the  first  COMMON  block  name  used  by  the  program 
unit  just  processed;  if  there  are  no  more  COMMON 
blocks,  return  to  the  referencing  program  unit.  If 
there  is  blank  COMMON,  bypass  and  fetch  the  next  name. 

7.  Search  the  Interface  Definition  file  for  COMMON  block 
name . 

b.  If  the  name  is  found,  get  the  COMMON  block  category. 

9.  If  category  1,  go  to  step  12. 

lU.  If  not  category  1,  store  the  size  and  go  to  step  12. 

11.  If  the  name  is  not  found,  store  the  name  and  size  in 

the  temporary  Interface  Definition  file. 

12.  Store  the  Interface  Definition  file  location  in  the 
symbol  table. 

13.  Search  the  COMMON  block  list  for  the  name;  if  not 
founa,  enter  the  Interface  Definition  file  location 
of  the  COMMON  block  in  the  COMMON  block  list. 

2.2.43  FUNCTION  ICOMP.  Given  an  array  IVAR  of  length  2 and 

a symbol  table  location,  this  subprogram  compares  IVAR  against 
the  first  two  columns  in  that  symbol  table  location.  ICOMP 
returns  a value  of  1 if  there  is  a match  and  0 if  not. 

Note  that  this  subprogram  is  used  only  for  the  IBM  360 
version  of  AUDIT  since  the  IBM  360  has  a four-character  word. 

A variable  may  be  as  many  as  six  characters  long,  so  two  words 
may  be  needed  to  store  it.  The  CDC  and  UNIVAC  1108  version  of 
AUDIT  can  store  the  va  iable  in  a single  word. 

2.2.44  SUBROUTINE  IMPTYP.  This  subroutine  first  examines  the 
"type  set"  flag.  If  the  type  has  already  been  set,  no  typing 
occurs.  If  not,  IMPTYP  performs  implicit  typing  by  examining 
the  initial  character  of  a variable  name  to  see  if  it  is 
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1,  J,  K,  L,  M,  oi  N.  It  it  is  one  of  these,  the  vat  table 
is  typed  INTEGER;  otheiwise  it  is  REAL.  If  the  vat  iable 
appeals  in  an  executable  statement,  the  "used"  flay  is  set. 

2. :.!.  4b  SUBROUTINE IN  IT  . This  subi  out  ine  processes  assign- 

ment statements  and  statement  functions  for  eirois  in  syntax 
and  transforms  these  statements  in  accoidance  with  the  lules 
outlined  in  Section  2.1.3.  INIT  lecognizes  the  following 
four  variations  of  the  model  statement  " va r i abl e=expr ess  ion " . 

Case  A - the  vat  iable  is  unsubscr  ipted 
Case  B - the  variable  is  the  function  name  within  the 
function  defining  subprogtam 
Case  C - the  vat  iable  is  subset  ipted 

Case  D - the  statement  is  a function  defining  statement 

1.  Get  assigned  variable.  If  a left  parenthesis  follows, 
go  to  step  4 . 

2.  If  an  equal  sign  follows,  do  one  of  the  following: 

a.  If  vat  iable  is  designated  a function  name,  check 
that  it  is  case  B. 

b.  If  variable  is  not  a function  name,  store  vat  iable 
in  symbol  table.  (This  is  case  A). 

3.  Set  left-side  type  and  go  to  Step  6. 

4.  If  this  is  a function  defining  statement  (case  D), 

a.  store  the  function  name  in  the  symbol  table 

b.  set  type  and  change  statement  class 

c.  store  in  statement  function  table 

d.  set  statement  function  flag 

e.  store  number  of  arguments. 

5.  If  this  is  a dimensioned  variable  (case  C), 

a.  set  type 

b.  CALL  PARSE  to  process  the  left-hand  side 

c.  CALL  BLKSTR  to  store  basic  blocks  for  flow 
analysis  and  go  to  Step  7. 

6.  Store  variable  in  basic  block  table. 

7.  CALL  PARSE  to  process  the  right-hand  side  and  store 
basic  blocks. 

a.  CALL  FNCSTR  to  process  function  references, 
y.  CALL  EXPRCK  to  check  validity  of  assignment. 

10.  CALL  BLKSTR  to  Store  basic  blocks  and  adjust  order  of 
var  iabl es  . 

11.  If  operating  under  the  var  iable  precision  mode,  CALL 
CNVRT,  if  necessary,  to  insert  function  references 
(QIREAL,  QICOMP,  QIDPRE). 

12.  If  operating  under  the  toll  call  mode,  and  if  the 
referenced  function  is  a function  module,  generate 
call  to  ROLCHK. 

2.2.46  SUBROUTINE  INTRIN.  After  processing  a program  unit, 
this  subroutine  is  called  to  check  if  any  basic  external  or 
intrinsic  function  names  have  been  misused. 


1.  Fetch  the  basic  exteinal  oi  intrinsic  function  name 
from  the  Interface  Definition  file. 

1.  Search  symbol  table  for  name. 

i.  If  found  and  the  name  is  in  var  iable  or  COMMON  block 

list,  issue  diagnostic. 

SUtlHOUTINE  10.  This  subroutine  processes  READ  and 
.vRIf'E  statements. 

1.  Check  keyword  spelling. 

1.  Cfreck  that  the  I/O  device  is  a simple  integer  var  iable 
i.  Rrocr.'ss  formatted  I/O  statements. 

1.  If  a FORMAT  statement  reference  is  made,  fetch  the 

statement  number  and  flag  it  in  the  statement  number 
table  as  having  been  referenced. 

■3.  Process  FORMAT  arrays. 

0.  CAI.I,  EXPR  and  CAI.L  PARSE  to  process  the  list. 

7.  rAbt,  lOSTR  to  store  basic  blocks. 

a.  If  operating  under  the  toll  call  mode,  transform  READ 
statements  into  comment  statements.  If  a READ  state- 
ment is  labeled,  generate  a CONTINUE  statement  with 
t he  same  1 abe 1 . 

z . 2 .Ati  SUBROUTINE  lOSTR.  This  subroutine  stores  the  basic 
olocks  after  an  i/0  list  is  encountered  in  a READ  or  WRITE 
statement.  Var  iables  which  occur  in  I/O  lists  fall  into 
t li  t ee  c 1 asses  : 

0 - I/O  variable 

1 - Subscr  ipt  or  implied  DO  parameter 
/ - Impl  ied  DO  index 

1.  Got  class  of  var  iable. 

/.  If  class  1,  store  var  iable  as  referenced. 

i.  If  class  U,  store  var  iable  as  defined  for  a READ 

statement  and  as  referenced  for  a WRITE  statement. 

4.  If  class  2,  store  as  such  and  adjust  its  position 
in  the  basic  block  table. 

2.2.4V  FUNCTION  IPREV.  Given  the  character  str  ing  A and  a 
starting  point  lA  in  the  str  ing,  this  function  returns  the 
value  1,  2,  or  3,  depending  upon  whether  the  first  preceding 
non-blank  character  is  a digit,  a letter,  or  some  other 
character,  respectively. 

2 . 2 . 5U FUNCTION  ITYPE.  Given  the  character  str  ing  A and  a 

starting  point  ID,  this  function  returns  the  value  1,  2,  or 
3,  depending  on  whether  the  next  non-blank  character  in  A 
is  a letter,  a digit,  or  some  other  character,  respectively. 

2.2.51 SUBROUTINE  LOGCHK.  Given  a char acter  str  ing  in  array 

A and  a starting  point  LOGST  in  that  array,  this  subroutine 
determines  whether  that  which  follows  is  a valid  logical 


constant  oi  opeiatoi  ot  lelational  opei atot  . The  vatiable 
I.OG  is  set  to  1 if  the  element  is  valid,  otheiwise  it  is 
set  to  zero.  The  vai  iable  LOGID  is  set  to  an  integei 
between  1 ana  11,  depending  on  the  opeiatoi  oi  constant 
encounteied,  as  shown  in  Figuie  2-Ub. 


OPERATOR/ CONSTANT  LOGID 


. LT.  1 

. LE  . 2 

. GT . 3 

.GE.  4 

. EQ  . 5 

. NE  . 6 

• OR.  7 

.AND.  8 

. NOT . 9 

.TRUE.  lU 

.FALSE.  11 


FIGURE  2-U8.  Valid  Opet atoi /Constant  Codes 


2.2. 82  SUBROUTINE  LOGIF.  This  subt out  ine  processes  logical 
IF  statements. 

1.  Check  keywoid  spelling. 

2.  CALL  PARSE  to  process  the  logical  expiession  and 
stole  function  lefeiences  and  basic  blocks. 

3.  Check  the  legality  of  the  statement  associated 
with  the  logical  IF. 

4.  Tiansfei  contiol  to  the  appi opi iate  segment  of  code 
foi  each  statement  type. 

8.  Pi ocess  assignment  statements. 

6.  Pi ocess  ASSIGN  statements. 

7.  In  the  case  of  GO  TO,  assigned  oi  computed  GO  TO, 
arithmetic  IF,  STOP,  and  RETURN  statements,  teimi- 
nate  the  basic  block  and  adjust  the  bianch  countei  . 
In  each  case,  contiol  could  pass  to  the  next  block, 
so  a "998"  flag  is  inserted  (see  FUNCTION  NXTBLK). 

8.  Process  GO  TO  statements.  The  number  of  branches 
out  of  the  block  is  2. 

9.  Process  assigned  GO  TO  statements. 

li).  Process  computed  GO  TO  statements. 

11.  Process  arithmetic  IF  statements. 

12.  For  Steps  9,  lu,  and  II,  the  number  of  branches 
out  of  the  block  is  incremented  by  one. 

13.  Process  CONTINUE,  STOP,  and  RETURN  statements. 

For  STOP  and  RETURN,  set  the  bianch  counter  to  2. 


2.2.5  3 SUBROUTINE  I.OOPCK.  After  each  program  unit  has  been 
processed,  thFs  subroutine  is  called  to  examine  the  basic 
blocK  table  to  ensure  that  no  transfer  of  control  within  the 
program  unit  violates  the  rule  regarding  branching  into  the 
range  of  a DO  from  outside  its  range.  To  accomplish  this, 
the  table  ISTAC'K  (COMMON  block  DOLOOP)  is  used  to  store  infor 
mation  regarding  each  DO  statement.  ISTACK  is  a 4 X N array, 
where  N is  the  number  of  DO  statements  in  the  program  unit. 
The  first  word  in  each  column  contains  the  index  in  the  state 
ment  number  table  of  the  terminal  statement  of  the  DO.  The 
second  contains  the  value  1 i f a DO  terminal  is  encountered 
and  U if  not.  When  processing  is  completed  the  second  word 
must  contain  a 1.  The  third  word  contains  the  index  in  the 
ISTACK  array  of  the  loop  in  which  the  DO  is  nested,  and  the 
fourth  word  points  to  the  induction  variable  in  the  symbol 
table.  In  the  following  example, 

DO  5 1=1,3 
DO  6 J=l,4 
IF( I .EQ.J)  GO  TO  10 

6 CONTINUE 
10  DO  7 K=l,5 

DO  9 L=1 ,4 
IF(K.EQ.L)  GO  TO  7 
9 CONTINUE 

7 CONTINUE 
5 CONTINUE 

iSTACK  contains  the  following  information: 

Word  1 - Indices  in  the  statement  number  table  of  the 
terminal  statements  for  DO  5,  6,  7,  and  9. 

Word  2 - All  zeros  before  processing  and  all  I's  after 
process  ing  . 

Word  3 - The  numbers  0,  1,  1,  and  3. 

Word  4 - Indices  in  the  symbol  table  for  variables  I, 

J , K , and  L . 

1.  Test  for  entries  in  ISTACK. 

2.  Initialize  IBLKST  and  IBLKND  to  the  indices  of  the 
beginning  and  the  end,  respectively,  of  the  first 
basic  block. 

3.  Fetch  the  index  in  ISTACK  of  the  DO  which  contains 
this  basic  block. 

4.  Fetch  the  number  of  branches  from  this  basic  block. 

5.  Test  whether  or  not  this  is  the  last  basic  block. 

6.  Set  the  variable  1ST  to  the  index  in  the  basic 
block  table  of  the  first  branch. 

7.  Search  for  the  "998"  flag  (see  FUNCTION  NXTBLK) 
indicating  a special  type  of  branch  which  passes 
control  to  the  next  block. 

8.  Fetch  the  index  of  the  basic  block  to  which  the 
branch  under  consideration  branches. 
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y.  Fetch  f I om  ISTACK  the  index  of  the  DO  loop  which 
contains  the  pieviously  identified  basic  block. 

10.  Test  whether  the  index  is  zero,  meaning  that  the 
basic  block  is  not  contained  in  a DO  loop.  In  this 
case  the  transfer  is  all  r ight . 

11.  Test  whether  the  branch  originated  outside  a DO  loop 
and  terminated  inside  a loop. 

12.  Test  whether  the  branch  began  and  ended  in  the  same 
DO  loop.  If  so,  go  to  statement  number  lUO  for 
testing  the  next  branch  from  this  basic  block. 

13.  Move  JLOOP  up  the  DO  stack  until  either  the  branch 
origin  and  the  termination  point  are  found  to  be  the 
same  DO  loop  ( JLOOP=KLOOP ) or  the  branch  or  igin  is 
found  to  be  outside  the  range  of  a DO  (JLOOP=0).  The 
latter  case  signals  improper  DO  nesting. 

2.2.54  SUBROUTINE  LVDLET.  This  subroutine  deletes  an  entire 
function  or  the  I POS^h  value  of  the  ITYP*^*’ type  from  the  top  or 
bottom  (depending  on  the  sign  of  IPOS)  of  a list  of  the 
requested  function.  IPOS  and  ITYP  are  explained  in  COMMON 
block  LVARGS. 

2.2.55  SUBROUTINE  LVEXIT.  This  subroutine  restores  the  syntax 
graph  if  GIRS  memory  becomes  full. 

2.2.5b  SUBROUTINE  LVFECH.  This  subroutine  reads  pertinent 
GIRS  system  variables  plus  the  GIRS  buffer  containing  the 
syntax  graph  structure. 

2.2.57  SUBROUTINE  LVFIND.  This  subroutine  retrieves  the 
IPOS^^'  value  of  the  ITYP^^  type  from  the  top  or  bottom  (depending 
on  the  sign  of  IPOS)  of  a list  of  values  of  a specified 
function.  IPOS  and  ITYP  are  explained  in  COMMON  block  LVARGS. 

LVFIND  traverses  multivalue  lists  sequentially  so  that  N 
calls  to  LVFIND,  to  access  the  first  through  the  nfti  items  on 
a multivalue  list,  result  in  N(N+l)/2  accesses  to  core.  A 
saved  index  facility  reduces  this  number  of  accesses  to  N at 
the  cost  of  four  words  of  core  for  every  call  to  LVFIND. 

These  words  take  the  form  of  four  separate  var  iables  in  the 
calling  sequence  for  each  call  to  LVFIND  with  a different 
node-link  pair  (IFUNC,  lARG)  as  input.  The  LVFIND  arguments 
must  be  initialized  to  zero  before  the  first  call  to  LVFIND 
for  the  associated  IFUNC  and  lARG  and  must  not  be  changed 
thereafter  by  the  user  program.  If  the  saved  index  option 
is  not  being  used,  the  function,  argument,  type  of  data 
desired,  and  other  input  required  in  the  COMMON  block  LVARGS 
is  initialized  and  LVFIND  is  executed  with  a dummy  var  iable 
as  its  four  arguments.  If  the  saved  index  option  is  being 
used,  the  arguments  are  a set  of  four  completely  different 
variables  for  each  separate  function-argument  pair  (IFUNC, 
lARG)  that  are  input. 
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2.2.58  SUBROUTINE  LVGRN . This  subroutine  assiqtis  J unique 
random  number  to  a qiven  GIRS  identifier.  Each  time  LVGRN 
is  referenced,  it  generates  a different  integer  between  one 
and  MEMSZE  (the  length  of  the  GIRS  buffet).  An  attempt  to 
define  more  than  MEMSZE  identifiers  will  terminate  the  pro- 
gram. 

2_._^.  59  SUBROUTINE  LVNSR'S.  This  subroutine  places  a triple 
into  a GIRL  structure. 

2.2.60  SUBROUTINE  LV^ETP^^  This  subroutine  initializes  the 
four  fields  in  the  GIRS  buffer,  the  variables  needed  for 
SUBROUTINE  LVGRN,  and  the  register  of  available  space. 

2_._2-61  SUBROUTINE  MODID.  This  subroutine  is  used  when 
operating  in  the  roll  call  mode  to  check  the  program  unit's 
roll  call  actions.  MODID  is  referenced  by  the  main  roll  call 
mode  subroutine  GENROL.  It  prints  out  what  is  written  on 
each  output  device  (X,  Y,  and  Z).  MODID  only  referenced 
for  a roll  call  mode  equal  to  2. 

2.2.62_  FUNCTION  NEXT_.  Given  the  character  string  A of  length 
N and  a starting  point  lA,  this  subroutine  sets  ‘■.he  value  of 
the  function  to  the  next  non-blank  character  found.  JPTR  is 
advanced  to  the  next  position  in  the  array.  If  no  more  non- 
blank characters  are  found,  NEXT  rrturns  with  the  value  'blank' 
and  sets  the  string  pointer  JPTR  to  N+1. 

2.2.63  FUNCTION  NXT^I^!^.  Given  a location  in  the  basic  block 
table,  which  is  a branch  to  a block,  this  function  returns 
the  location  of  the  block  which  the  branch  points  to. 

Case  1 - Branch  is  a "999",  indicating  RETURN  or  STOP. 

Set  NXTBLK=0  and  return. 

Case  2 - Branch  is  a "998",  indicating  a branch  to  the 

next  basic  block.  Compute  starting  location  of 
next  block. 

Case  3 - Branch  is  to  a statement  label.  Fetch  starting 
location  of  block  from  the  statement  number 
table . 

2_._2_._64  Sj^BROUTI  NE  PARSE  This  subroutine  processes  assign- 
ment, CALL,  and”  I/O  statements  as  a S’  r ies  of  terminal  symbols. 
If  it  is  possible  to  trace  through  the  syntax  graph  from  a 
start  to  a stop  state,  then  the  statement  is  declared  to  be 
syntactically  correct. 

1.  CALL  subroutines  PHONEY  and  LVFECH  to  read  the 
syntax  graph  and  initialize  GIRL  variables. 

2.  Initialize  appropriate  variables  for  parsing  the 
next  statement. 

3.  Zero  out  the  parser  tables. 
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4.  Store  the  expression  to  be  parsed  (created  by 
SUBKOUTINK  KXPR)  in  a list  structure  so  that  it 
Will  be  in  a fotm  suitable  for  parsing. 

5.  CALL  HLCOG  to  perform  the  parse. 

6.  CALL  PHNTS  to  generate  error  messages. 

7.  Delete  all  GIRL  structures  which  were  created  by 
the  parse. 

^._2._65  SUBROIP^INL  PilONLY.  This  subroutine  initializes  GIRL 
variables. 

SUBROUTINE  PRNTS.  To  guard  against  the  toxens  (nodes 

and  links)  already  recognized  being  lost  when  a syntax  error 
occurs,  this  subroutine  places  each  token  recognized  so  far 
into  a buffer  for  printing. 

^._2._6_7  SUBROUTINE  PROG_.  This  subroutine  is  only  used  when  a 
main  program  is  being  analyzed.  For  the  CDC  version  of  AUDIT, 
PROG  processes  the  PROGRAM  statement,  which  must  precede  a main 
program  on  the  CDC.  The  syntax  of  the  PROGRAM  statement  is 
checked  and  the  main  program  name  is  stored  in  the  symbol 
table.  For  the  IBM  360  and  UNIVAC  1108  versions  of  AUDIT, 

PROG  assigns  the  name  MAIN  to  a main  program  and  enters  that 
name  in  the  symbol  table. 

2_._2  ._6  8 ^[^ROUTINES  Q1C0MJ^,_  _Q1  OPRE  , and  QlREAL.  These 
packages  of  subroutines,  available  as  card  ihput,  are  used 
when  operating  under  the  variable  precision  mode.  QICOMP, 
QlDPRE,  and  QlREAL  perform  truncation  during  operations 
between  complex,  double  precision,  and  real  numbers,  respec- 
tively. Each  package  contains  one  version  of  each  of  the 
three  subprograms  which  will  truncate  the  n rightmost  bits 
during  each  operation.  For  each  value  of  n for  which  the 
user  wishes  to  perform  the  variable  precision  calculation, 
a diffeient  version  of  a package  must  be  used.  Each 
package  consists  of  the  three  subprograms  for  a single  bit 
configuration.  There  is  a separate  and  different  set  of 
packages  for  each  AUDIT  processor.  For  the  CDC  6000,  there 
ate  11  packages  that  simulate  word  lengths  ranging  from  30 
to  40  bits.  For  the  UNIVAC  1108,  there  are  six  packages 
that  simulate  word  lengths  ranging  from  30  to  35  bits.  The 
IBM  360  has  eight  packages  that  simulate  word  lengths  ranging 
from  24  to  31  bits. 

The  CDC  has  a 60-bit  word  consisting  of  a 12-bit 
exponent  and  a 48-bit  fraction.  Each  package  of  variable 
precision  functions  simulates  a certain  word  length  by 
masking  the  appropriate  number  of  low  order  (rightmost)  bits 
from  the  fraction  part  of  the  word.  For  the  CDC,  a 30-bit 
word  length  is  simulated  by  masking  30  bits.  A 40-bit  word 
length  is  simulated  by  masking  20  bits.  For  the  UNIVAC  1108 
and  the  IBM  360,  the  fraction  part  of  the  word  is  masked  in 
the  same  manner. 
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l.Z.b'i  SUBROUTINh  RKALCK . Given  the  chaiactei  st(  inq  A 
and  a staitinq  point  this  suoioutine  detei  mines  whether 

oi  not  the  next  suiist  i inq  is  a leal  numbei  . HEALCK  sets 
IHKAL  to  I if  the  substi  inq  is  a teal  number  and  0 if  it  is 
not  . 

^^2.70 SUBHOUTINK  HfclCOG.  This  subroutine  checks  the  syntax 

of  the  input  str  inq  aqainst  the  syntax  qtaph. 

2^.71  SUBROUTINE  RECOV.  This  subroutine  provides  for 
backup  recovery.  FORTRAN  is  a non-tinite  state  lanquaqe, 
meaninq  that  there  may  be  mote  than  one  link  eminatinq  from 
a source  node.  If  the  wt onq  path  has  been  selected  while 
tracing  through  the  syntax  graph,  RECOV  is  referenced  to  back 
up  the  trace  to  the  correct  node,  so  that  a different  path 
can  be  selected. 

2.2.72  PROGRAM  ROLCAL . For  the  CDC  version  of  AUDIT,  ROLCAL 
is  the  name  assigned  to  the  main  program  generated  by  sub- 
routine GENROL  (see  Section  2.2.37).  For  the  IBM  360  and 
UNIVAC  1108  versions  of  AUDIT,  this  main  program  is  generated 
without  a name  and  without  a PROGRAM  statement.  See  subroutine 
GENROL  tor  an  explanation  of  this  main  program. 

^.2.73  SUBROUTINE  ROLCHK . This  subroutine  packs  the  charac- 
ters from  Hollerith  variables  of  the  argument  list  into  one 
word,  and  wr  ites  it  onto  logical  unit  3.  Each  of  the  six 
argument  list  variables  contain  one  character.  The  six 
characters  (some  may  be  blank)  make  up  a subprogram  name. 

The  characters  in  the  argument  list  are  generated  by  SUBROU- 
TINE CALL2. 

2.2.74  SUBROUTINE  SEARCH.  Given  the  identifier  NXTID,  this 

subroutine  searches  the  symbol  table  for  an  occurrence  of  the 
identifier  and  sets  ISRCH(l)  to  1 if  the  identifier  occurs  as 
a var  iable  name  and  U otherwise.  ISRCH(2)  is  set  to  1 if  the 
identifier  occurs  as  a subprogram  and  0 otherwise. 

2.2.75  SUBROUTINE  SEMANT.  This  subroutine  checks  a state- 
ment for  correct  semantics.  For  example,  if  the  vat  iable  A 
is  dimensioned  A(1J),  the  statement  A(B)=1.  is  synt act ical 1 y 
correct  but  semantically  incorrect,  since  B is  real  instead 
of  integer  . The  parser  will  accept  any  constant  or  vat  iable 
as  a subset  ipt,  therefore  an  error  in  the  type  of  dimension- 
al ity  of  a subset  ipt  must  be  checked  by  a semant  ics  r out  me. 

1.  Check  for  mixed  mode  expressions. 

2.  Check  for  correctness  of  subscripts. 

3.  Insert  call  to  var  iable  precision  functions. 

4.  Keep  track  of  function  call  levels. 

0.  Build  the  parser  table. 
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7 6 SUBROUTINE  SEPAR.  Given  the  s t a r t i ng  point  S E PST 

in  the  str  ing  A,  this  subioutine  sets  the  var  table  ISEP  to 
1,  0,  o(  -1,  depending  on  whethei  the  next  substi  ing  is  a 
val id  sepai atot  , is  not  a sepai atot  , oi  is  an  inval  id  sep- 
aiatoi,  respectively.  A valid  separator  is  a comma , a 
slash,  or  a ser  ios  of  slashes. 

2.2.77 SUBROUTINE  SIMP.  This  subroutine  checks  the  RETURN, 

STOP,  CONTINUE,  and  BLOCK  DATA  statements  for  correct 
spelling.  For  the  RETURN  and  STOP  statements,  the  basic 
block  (associated  with  flow  analysis)  in  which  they  occur 
is  term  inated  . 

2.2.7b SUBROUTINE  SLEVEL.  While  tracing  through  the  syntax 

graph,  this  subroutine  stacks  the  nodes  that  were  seen,  so 
that  a back  up  action  can  be  performed  if  necessary. 

2.2.7^  SUBROUTINE  SQUEEZ.  Given  a character  str  ing  of 
length  M in  array  D,  this  subroutine  removes  all  blanks  and 
adjusts  M accordingly.  Holler  ith  fields  are  not  affected. 

2.2.b0  SUBROUTINE  SSTOP.  After  a str  ing  has  been  completely 
traced,  this  subroutine  verifies  that  the  current  state  is  a 
val id  final  state . 

^_2_.^_1_  SUBROUTINE  STATNO.  This  subroutine  performs  the 
following  functions: 

a.  Checks  to  see  that  the  statement  being  processed 
is  labeled  and  that  the  label  is  valid, 

o.  Determines  whether  the  statement  should  begin  a 
new  basic  tjlock.  If  so,  STATNO  closes  the  old 
block  and  initiates  a new  one. 
c.  Checks  for  proper  DO  loop  nesting. 

1.  Check  for  the  presence  of  a statement  label. 

2.  Process  unlabeled  statements. 

j.  Process  END  statements;  the  END  statement  must  be 
preceded  by  some  type  of  branch  statement  (except 
a logical  IF)  or  a RETURN  or  STOP  statement 
(BLOCK  DATA  subprograms  are  excepted). 

4.  Store  the  number  of  branches  contained  in  this 
program  unit  in  the  last  basic  block.  This  concludes 
the  processing  for  END  statements. 

5.  Detect  FORMAT  statements. 

b.  If  the  statement  being  processed  is  the  first 

executable  statement,  go  to  step  9.  If  the  preceding 
statement  ended  a basic  block,  go  to  step  17. 

7.  If  the  preceding  statement  was  the  terminal  statement 
of  a DO  loop,  go  to  step  16. 

8.  If  the  preceding  statement  contained  transfers  to 
other  blocks  but  not  this  one,  issue  a diagnostic. 
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. Beilin  piocessinq  the  first,  executable  statement. 
Initialize  the  basic  block  table  and  qo  to  Step  13. 

10.  Process  the  labeled  statement.  If  the  labeled  state- 
ment is  an  KND  statement,  issue  a diaqnostic. 

11.  Check  the  statement  number  to  see  that  it  occupies 
the  proper  position  in  the  statement. 

Iz.  Check  for  duplicate  statement  numbers.  Set  the 
"defined"  flag  in  the  statement  number  table  and 
store  the  statement  type  in  the  statement  number 
table. 

13.  It  the  statement  beinq  processed  is  a f’ORMAT  state- 
ment, RETURN. 

14.  If  this  labeled  statement  is  the  first  executable 
statement  in  the  proqram  unit,  qo  to  Step  'i . 

la.  If  the  previous  statement  ended  a basic  block,  go  to 
Step  17. 

lb.  Increment  the  statement  count  for  this  block.  Store 
a "yya"  flag  in  the  basic  block  table  to  signify 
that  control  may  pass  to  this  new  block  from  the 
previous  block.  Set  the  branch  counter  into  the 
block  to  1.  See  FUNCTION  NXTBLK . 

17.  Close  out  old  basic  blocks  and  initialize  the  new  one. 

18.  Set  the  start  of  the  new  block. 

19.  Store  the  pointer  to  the  new  block  and  the  branch 
count  in  the  old  block. 

2U.  If  the  preceding  statement  is  the  terminal  statement 
of  a DO  loop,  make  some  adjustments  so  that  the 
induction  var  iable  becomes  undefined  at  the  end  of 
that  statement  rather  than  at  the  beginning. 

21.  Reinitialize  the  branch  counter  NBRNCH. 

22.  Store  the  number  of  the  current  DO  loop  in  the  new 
Das ic  block. 

23.  If  the  statement  is  not  labeled,  RETURN. 

24.  Store  the  index  of  the  basic  block  headed  by  a 
statement  label  in  the  statement  number  table  entry 
corresponding  to  that  label. 

25.  Process  statements  which  terminate  DO  loops. 

26.  If  this  statement  does  not  end  the  current  loop, 
issue  a diaqnostic. 

27.  Check  that  the  proper  type  of  statement  terminates 
the  DO  loop. 

28.  Set  an  entry  in  the  DO  stack  to  indicate  that  the 
current  DO  loop  is  complete. 

29.  Flag  the  induction  var  iable  in  the  DO  loop  as 
unde  f i ned  . 

JU.  Search  the  DO  stack  for  the  first  unsatisfied  DO, 
which  then  becomes  the  current  loop. 

31.  If  there  are  no  further  unsatisfied  DO  loops,  set 
ILOOP  to  zero  and  RETURN. 

32.  Ctiock  whether  more  than  one  DO  is  terminated  by  this 
statement  . 

33.  Make  appropriate  changes  in  the  DO  stack  and  set  the 
induction  variable  as  undefined. 
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2_._2  . J^TKNC  . When  a statement  function 

reTetence  is  enco^untered , this  subroutine  checks  the  calling 
sequence  against  the  argument  list  in  the  function  defining 
statement . 

1.  Fetch  the  number  of  arguments  from  the  symbol  table. 

2.  Fetch  the  number  of  arguments  encountered  by  the 
parser  and  verify  the  correctness. 

3.  Check  arguments  for  proper  dimensionality  (must  be 
zero)  and  proper  type. 

Given  the  identifier  NXTID  and  a 
class  (IDTYP=1  for  variable,  IDTYP=2  for  subprogram,  IDTYP=3 
for  COMMON  block,  this  subroutine  stores  the  identifier  in 
the  next  available  location  in  the  symbol  table  and  links  it 
to  the  last  identifier  of  that  class. 

2.2.84  SUBROUTINE  STSRCH.  Given  a statement  number  N2,  this 
subroutine  searches  the  statement  number  table  STATRA  for  that 
statement  number,  and  stores  it  in  the  table  if  it  is  not 
already  there.  In  any  case,  the  index  of  the  label  is  stored 
in  LOC . 

^._:^._85  SUBROUTI . This  subroutine  processes  SUBROUTINE 
and  FUNCTION  statements. 

1.  Check  keyword  spelling. 

2.  Process  the  list  of  formal  parameters  by  storing 
the  names  in  the  symbol  table. 

3.  Determine  that  there  are  no  more  than  63  arguments. 

4.  If  function  is  typed,  store  type  in  the  symbol  table. 

2.2.86  SUBROUTINE  SUBCHK.  After  the  program  unit  has  been 
processed,  this  subroutine  checks  its  name  and  argument  list 
against  the  Interface  Definition  file. 

1.  Increment  subroutine  counter  anci  check  for  overflow. 

2.  Fetch  the  number  of  arguments  and  their  types  from 
the  symbol  table. 

3.  If  the  subprogram  name  has  already  been  encountered, 
go  to  step  7. 

4.  Search  the  Interface  Definition  file  for  the  sub- 
program name. 

5.  If  found,  store  file  location  in  symbol  table  and 
go  to  step  8. 

6.  If  not  found,  issue  a diagnostic  and  store  the  name 
in  the  temporary  Interface  Definition  file.  Create 
and  store  an  Interface  Definition  for  the  subprogram 
based  on  this  occurrence  (stored  in  temporary  file). 

7.  Fetch  the  Interface  Definition  file  location  of 
subprogram. 
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tt.  Fetch  the  number  ot  arguments  and  program  unit  type 
and  class,  and  check  validity. 

V.  Check  the  variables  in  the  argument  list  for  correct 
type,  dimensionality,  and  I/O  status. 

SUBROUTINE  SaITCH.  This  subroutine  takes  an  identi- 
fier out  of  the  variable  name  list  and  puts  it  into  the 
function  name  list  in  the  symbol  table.  The  need  for  this 
action  arises  when  a statement  of  the  type  A=F(13)  follows  a 
statement  of  the  type  INTEGER  F.  F is  initially  put  on  the 
variable  list  and  the  second  statement  requires  that  it  be 
put  on  the  function  list. 

1.  Find  the  variable  entry  which  points  to  F. 

2.  Link  this  variable  to  the  variable  following  F. 

i.  Link  F into  the  function  list. 

2. 2.  HR  SUBROUTINE  SYMTAB.  This  subroutine  displays  the 
symbol  table. 

1 . Print  head  ings . 

2.  Fetch  the  next  variable  and  its  type,  dimensionality, 
and  relocation  from  the  symbol  table  and  display  it. 

i.  After  all  variables  have  been  displayed,  fetch  the 
next  external  from  the  symbol  table  along  with  its 
type  and  number  of  arguments  and  displa/  it. 

4.  After  all  externals  have  been  displayed,  fetch  the 
next  statement  function  from  the  statement  function 
1 ist  and  fetch  its  type  and  the  number  of  arguments 
from  the  symbol  table  and  display  it. 

5.  After  all  statement  functions  have  been  displayed, 
display  all  statement  labels. 

6.  After  displaying  all  statement  labels,  fetch  COMMON 
blocks  and  their  lengths  from  the  symbol  table  and 
d isplay  them . 

2.2.8S*  SUBROUTINE  TYPE.  This  subroutine  processes  the 
INTEGER,  REAL,  DOUBLE  PRECISION,  COMPLEX,  and  LOGICAL  state- 
ments by  first  checking  keyword  spelling  and  then  adding  to 
the  symbol  table  the  type  and  dimension  information  contained 
in  the  list.  Considerable  error  checking  is  performed  in- 
cluding the  detection  of  array  bounds  that  are  outside  of 
allowable  range,  the  illegal  use  of  variable  dimension  in  TYPE 
statements,  dimensioning  previously  dimensioned  variables, 
typing  previously  typed  variables,  and  other  illegal  uses  of 
dimensioned  variables. 

2.2. '^0  Blank  COMMON  Storage. 

1.  A(1J26)  - This  array  holds,  in  A1  format,  the  FORTRAN 

statement  currently  being  processed.  For  most  of  the 
program  unit  descriptions,  this  array  is  referred  to 
as  the  character  string  A. 
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D(500)  - This  array  is  used  to  store  the  result  of 
a call  to  subroutine  GNLE.  After  such  a call,  array 
D contains,  in  Al  format,  the  next  operator,  identi- 
fier, constant,  or  separator  in  the  FORTRAN  statement 
being  processed. 

3.  IDTBL(8,500)  or  IDTBL ( 1 1 , 500 ) - This  symbol  table 

array  contains  information  regarding  the  symbols  used 
in  the  program  unit  being  processed.  These  symbols 
fall  into  the  following  three  classes:  COMMON  block 
names,  variable  names,  and  subprogram  names.  IDTBL 
(8,500)  is  used  for  the  CDC  and  UNIVAC  1108  versions 
of  AUDIT.  IDTBL  (11,500)  is  used  for  the  IBM  360  ver- 
sion of  AUDIT.  Up  to  500  symbols  may  be  entered  into 
the  IDTBL  array.  For  each  symbol,  the  eight  or  eleven 
columns  of  the  array  are  used.  IDTBL(8,500)  for  the 
CDC  is  constructed  as  follows: 

Word  1 - Contains  the  symbolic  name  in  A6  format. 
Word  2 - Contains  a pointer  to  the  next  symbol  in 
the  class  of  which  this  is  a member. 

Word  3 - Contains  flags  and  information  about  the 
symbol : 

Bit  1 is  1 if  the  symbol  is  dimensioned  and  0 
if  not. 

Bits  2-7  contain  the  number  of  dimensions  or 
the  number  of  arguments  depending  on 
whether  the  symbol  is  a variable  or  a 
subprogram. 

Bits  8-10  contain  the  variable  or  function 

type  (1  for  real,  2 for  complex,  3 for 
double  precision,  4 for  integer,  5 for 
logical). 

Bit  11  is  1 if  the  symbol  has  been  typed  and  0 
if  not. 

Bit  12  is  1 if  the  symbol  is  a formal  para- 
meter and  0 if  not . 

Bit  13  is  1 if  the  symbol  is  a variable 
dimension  and  0 if  not. 

Bit  14  is  1 if  the  symbol  has  been  declared 
in  a DATA  statement  and  0 if  not. 

Bit  15  is  used  by  subroutine  FLOWCK  to  suppress 
printing  of  multiple  error  messages. 

Bit  16  is  1 if  the  symbol  is  in  COMMON  and  0 
if  not . 

Bit  17  is  1 if  the  symbol  is  equivalenced  and 
0 if  not . 

Bit  18  is  1 if  the  symbol's  Interface  Defini- 
tion file  location  is  known  and  0 if  not. 
(in  this  case  the  symbol  must  be  a sub- 
program name ) . 

Bit  19  is  1 if  the  symbol  is  a statement 
function  name  and  0 if  not. 
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Bits  ly-i6  contain  the  first  subscript  (if  the 
symbol  is  an  array  name)  or  contain  the 
symbol's  Interface  Definition  file  lo- 
cation ( if  the  symbol  is  a subprogram 
name ) . 

Bit  37  is  1 if  the  symbol  (must  be  a formal 
parameter)  is  input  and  U if  not. 

Bit  38  is  1 if  the  symbol  has  appeared  in  an 
executable  statement  and  0 if  not. 

Word  4 - If  the  symbol  is  a variable  which  is  an 
array,  this  word  contains  the  second 
and  third  dimensions  of  the  array  (if 
any)  in  two  consecutive  lb-bit  fields, 
respectively.  If  the  symbol  is  a COMMON 
block  name,  this  word  contains  the  size 
of  the  block. 

Words  3 and  6 - Contain  COMMON  block  information. 

If  the  symbol  is  a COMMON  block  name. 
Words  5 and  6 point  to  the  first  and 
last  names  in  the  block,  respectively. 

If  the  symbol  is  the  name  of  a variable 
in  COMMON,  Word  5 points  to  the  next 
variable  in  the  block  and  Word  6 points 
to  the  name  of  the  block. 

Words  7 and  8 - Contain  EQUIVALENCE  information. 

If  the  symbol  has  been  declared  in  an 
EQUIVALENCE  statement.  Word  7 points  to 
the  next  variable  in  the  chain  and  Word 
8 contains  the  offset. 

IDTBL(b,5U0)  for  the  UNIVAC  11U8  is  constructed  in  the 
same  manner  as  for  the  CDC  except  for  the  following  exceptions. 

Word  3; 

1.  Bit  15  is  the  same  as  bit  37  of  the  CDC. 

2.  Bit  ly  is  the  same  as  bit  38  of  the  CDC. 

3.  Bit  20  is  the  same  as  bit  ly  of  the  CDC. 

4.  Bits  20-36  are  the  same  as  bits  iy-36  of  the 

CDC.  Note  that  bit  20  is  used  twice  but  will 
never  conflict  with  the  other  use. 

Word  6 is  also  used  in  the  same  manner  as  bit  IS  of  the 
CDC  for  word  3. 

IDTBL( 1 1 , SOO ) for  the  IBM  360  is  constructed  as  follows: 

Words  1 and  2 - Contain  the  symbolic  name  in  A4 , A2 

format. 

Word  3 - Contains  flags  and  information  about  the 

symbol . 

Bits  1-14  . See  bits  1-14  of  IDTBL(8,500)  for 
the  CDC. 

Bit  15  is  1 if  the  symbol  (must  be  a formal 
parameter)  is  input  and  0 if  not. 
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Bits  16-lS.  See  bits  16-19  of  I DTBb  ( H , 9(JU  ) 
for  the  CDC. 

Bit  20  is  used  by  subroutine  KLOWCK  to  suppress 
printing  of  multiple  error  messages. 

Bit  21  is  1 if  the  symbol  has  appeared  in  an 
executable  statement  and  0 if  not. 

Bits  22-2 i are  not  used. 

Bits  24-32  contain  the  symbol's  Interface 

Definition  file  location  (if  the  symbol  is 
a subprogram  name). 

Word  4 - See  Word  2 of  IDTBL(H,500)  for  the  CDC. 

Words  3-7  contain  the  first,  second,  and  third  sub- 
scripts (if  the  symbol  is  a variable  which  is  an 
array)  . 

Words  8-y  - See  Words  5 and  6 of  IDTBL(8,50U)  for  the 
CDC  . 

Words  10-11  - See  Words  7 and  8 of  IDTBL(8,5U0)  for 
the  CDC. 

4.  INITID(J)  - This  array  contains  pointers  to  the 

IDTBL  array  (symbol  table)  for  the  first  entries  in 
each  of  the  symbol  classes:  variable,  subprogram, 

and  COMMON  block  name,  respectively. 

3.  LASTID(j)  - This  array  contains  pointers  to  the 

IDTBL  array  (symbol  table)  for  the  last  entries  in 
each  of  the  symbol  classes;  variable,  subprogram, 
and  COMMON  block  name,  respectively. 

6.  1SKCH(3)  - Each  member  of  this  array  contains  1 or 
U,  depending  on  whether  or  not  a symbol  is  the  name 
of  a variable,  subprogram,  or  a COMMON  block. 

7.  JPTR  - This  integer  variable  points  to  the  current 
character  position  in  array  A. 

8.  N - The  number  of  characters  in  the  statement  being 
processed . 

9.  M - The  length  in  characters  of  the  language  element 
(identifier,  operator,  separator,  constant)  just 
identified  by  subroutine  GNLE. 

lU.  JTYP  - Set  by  subroutine  GNLE  according  to  the  kind 
of  language  element  encountered  in  the  input  string. 
See  Figure  2-U7. 

11.  LSTART  - Points  to  the  beginning  of  the  language 
element  in  array  A just  recognized  by  subroutine 
GNLE. 
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12.  N2  - The  binary  equLvcaient  of  the  character  string 
just  identified  by  subroutine  GNLE  as  an  integer. 

li.  lENCNM  - Contains  the  function  name  in  A6  format 

(for  the  CDC  and  UNIVAC  1108  versions)  or  the  sym- 
bol table  location  of  the  function  name  (for  the 
IBM  ibU),  if  the  program  unit  being  analyzed  is  a 
function  subprogram. 

14.  LOGID  - Set  by  subroutine  LOGCfIK;  denotes  the  integer 
code  for  the  logical  operator  of  the  character  string 
currently  being  considered.  See  Figure  2-08. 

15.  NXTID  or  NXTID(2)  - The  identifier  currently  being 
considered;  A6  format  in  NXTID  (used  for  CDC  and 
UNIVAC  1108),  and  A4  and  A2  format  in  NXTID(2)  (used 
for  IBM  360 ) . 

16.  IDTYP  - An  indicator  of  the  class  (1  for  variable, 

2 for  subprogram,  3 for  COMMON  block)  to  which  the 

identifier  in  NXTID  will  be  attached.  IDTYP  is  used 
as  input  to  subroutine  STORE. 

17.  NID  - A count  of  the  number  of  entries  in  the  symbol 
table . 

18.  LOC  - Normally  contains  a pointer  into  the  symbol 

table  to  the  identifier  which  has  just  been  stored 

by  subroutine  STORE. 

19.  LTYP  - Set  to  9 if  the  statement  being  processed  is 
a logical  IF  statement.  The  statement  following  the 
logical  IF  is  classified  by  variable  ITYP. 

2(J.  ITYP  - Set  by  subroutine  CLASS  to  indicate  what  kind 
of  FORTRAN  Statement  is  in  array  A.  See  Figure  2-04. 

21.  IBLKDT  - Set  to  1 by  the  main  program  if  the  program 
unit  being  analyzed  is  a BLOCK  DATA  subprogram  and  0 
if  not. 

22.  MODE  - This  value  is  submitted  as  input;  it  indicates 
which  mode  is  to  be  used: 

1 - Variable  precision  mode  and/or  audit  mode 

2,3  - Roll  call  mode. 

23.  lERR  - An  error  flag  set  by  subroutine  BUILD: 

1 - Too  many  continuation  statements 

2 - An  end-of-file  has  been  encountered. 
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24.  IDES  - Subroutine  REALCK  sets  IDES  to  1 if  a teal 
number  is  double  precision  and  0 if  it  is  not. 
Subroutine  DESCRP  sets  IDES  to  1 if  a format  field 
descriptor  is  valid  and  0 if  it  is  not. 

2. 2. '41  COMMON  Block  BASBLK  . 


1.  IBLOCK(25UO)  - This  array  (the  basic  block  table) 
contains  information  regarding  the  definition  of 
variables  and  the  flow  of  control  through  the  pro- 
gram unit. 

2.  NBLOCK  - Counter  which  keeps  track  of  the  number  of 
entr  ies  in  the  basic  block  table. 

3.  NB  - Set  to  1 when  a new  basic  block  is  started. 

4.  NBRNCH  - On  a block  terminal  statement,  set  to  the 
number  of  branches  from  the  block. 


Dur  ing  the  processing  of  each  program  unit,  the  basic 
blocks  which  represent  the  program  unit  structure  are  con- 
structed. A basic  block  contains  the  information  represented 
by  a group  of  statements  which  physically  appear  together  in 
the  program,  are  located  within  the  same  DO  loop,  and  are 
executed  together.  See  Section  2.1.4  for  an  explanation  of 
what  begins  and  what  terminates  a basic  block.  The  basic 
block  table  ( I BLOCK ( 2 500  ) ) usually  contains  information  on 
more  than  one  block  (except  for  a very  simple  program  unit). 
The  basic  blocks  are  of  variable  length  and  each  block  points 
to  the  starting  location  of  the  next  block. 


The  first  word  (location)  for  each  block  is  the  "head  of 
the  block".  It  contains  the  following  information: 


Bits 

IBM  360  CPC,  UNIVAC  1108 


1-6 


1-6 


7-12 


7-12 


13-24  13-28 

25-32  29-36 


Contents 


A count  of  the  number  of 
possible  branches  from  the 
block. 

A pointer  into  ISTACK  (see 
COMMON  block  DOLOOP)  to  the  DO 
loop  containing  the  block. 

This  field  is  zero  if  the  block 
is  not  within  a DO  loop. 

A pointer  to  the  next  block. 

A pointer  into  STATRA  (see 
COMMON  block  LABELS)  to  the 
statement  number  of  the  block. 
This  field  is  zero  if  the 
block  has  no  statement  number  . 
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The  locations  following  the  "head  of  the  block"  contain 
intoimation  about  the  vat  iables  in  the  block,  stoi ed  one 
vat  lable  pet  word  accoidinq  to  the  followinq  sche.Tie: 


lUJl  n IhUU: 
20U1  n 2aU0 ; 
iUUl  n JdOU : 
4U01  n 4dU0: 
aUUl  n-  ittUU  ; 
bUUl'  n’  65UU: 
70U1  n-  7dU0  : 


n-lUUO  points  to  the  symbol  table  location  (see 
IDTBL  at t ay  in  blank  COMMON)  of  the  vat  table. 

The  vat  iable  is  uef  ined  by  this  block. 
n-200U  points  to  the  symbol  table  location  of  the 
vat  laole.  The  vat  iable  is  tefetenced  by  this 
block. 

n-JUOO  points  to  the  symbol  table  location  of  the 
vat  iable.  The  vat  iable  is  an  induction  vat  iable 
in  this  block. 

n-4UOO  points  to  the  symbol  table  location  of  the 
vat  iable.  The  vat  iable  is  assigned  a value  (by 
an  ASSIGN  statement)  in  this  block. 
n-dOUO  points  to  the  symbol  table  location  of  the 
vat  iable.  The  vat  iable  appeals  in  an  assigned  GO 
TO  in  this  block. 

n-6G0U  points  to  the  symbol  table  location  of  the 
vat  iable.  The  vat  iable  is  undefined  in  this 
block . 

n-7000  points  to  the  symbol  table  location  of  the 
variable.  The  variable  is  a DO  pat ametet  . 


The  remaining  locations  of  the  block  contain  information 
about  branches  from  the  block,  stored  one  variable  per  word 
according  to  the  following  scheme; 


1 n-200:  blanch  to  the  basic  block  pointed  to  by  n,  which 

is  a location  in  the  statement  number  table  (see 
COMMON  block  LABELS),  Once  in  the  statement 
number  table  find  the  block  pointed  to. 
n=yyB:  branch  to  next  block 

n=yyy;  stop  or  RETURN 


The  IBLOCK  array  is  structured  as  follows: 


■Vot  d 1 : 

Words  2 - M : 

Wot  ds  ( M+1 ) -N : 
Word  N + 1 : 

Woids  (N+l)-L: 
Wor  ds  { L + 1 ) -J : 
Wot  d J+  1 : 

etc  . 


Head  of  block  1 

Vat  iable  info,  for  block  1 

Branch  info,  for  block  1 

Head  of  block  2 

Vat  iable  info,  foi  block  2 

Branch  info,  for  block  2 

Head  of  block  3 


Words  1,  N+1,  and  J+1  ate 
(see  Word  1 description)  which 
tion.  All  other  words  contain 
the  preceding  paragraphs. 


each  separated  into  four  fields 
give  the  head  of  block  infotma- 
the  vat  iable  n as  desct  ibed  in 


.Ji. 
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To  illustrate  the  construction  of  the  IBLOCK  array,  the 
following  pro^jram  unit  is  inalyzed.  Items  needed  for  the 
subroutine  - symbol  table  (IDTBL  array  in  blank  COMMON), 
statement  number  table  (STATRA  array  in  COMMON  block  LABELS), 
DO  loop  stack  (ISTACK  array  in  COMMON  block  DOLOOP),  basic 
blocks,  and  the  basic  block  table  (IBLOCK  array  in  COMMON 
block  BASBLK)  -are  included. 

SAMPLE  PROGRAM  UNIT 


BASIC  BLOCK 

NUMBER  STATEMENT 

SUBROUTINE  SORTS (NUM,N)  1 

DIMENSION  NUM( 1 ) , IPS{  10)  2 

DATA  (I  PS (I), 1 = 1, 10)710,0,8,7,6, 5, 4, 3,  3 

2,1/ 

1 DO  111=1, 10  4 

2 IF(N.GT. IPS(  II  ) ) GO  TO  2 5 

3 1 CONTINUE  6 

4 2 JJ=II+1  7 

DO  10  NN=JJ ,10  8 

5 IP=IPS(NN)  0 

DO  201=1, IP  10 

6 K=N/IP  11 

IP(I+K*IP-N)  21,21,22  12 

7 22  K=K-1  13 

8 21  DO  20  J = 1 ,K  14 

9 M=I+IP*(J-1)  Id 

MM=M+IP  16 

10  30  IF(NUM(M)-NUM(MM) ) 20,20,23  17 

11  23  ITEMP=NUM(M)  18 

NUM( M) =NUM( MM)  lO 

NUM( MM) =ITEMP  20 

IF(M-I)  20,20,24  21 

12  24  MM=M  22 

M=M-IP  23 

GO  TO  30  24 

13  20  CONTINUE  25 

14  10  CONTINUE  26 

RETURN  27 

END  2 8 


li 


SYMBOL 

TABLE 

STATE MEOT_ 

NUMBER  TABLE 

SECOND 

SECOND 

STATEMENT 

SUBSCRIPT 

NAM_E 

SUBSCRIPT 

NUMBER 

1 

SORTS 

1 

1 

2 

NUM 

2 

2 

N 

3 

10 

4 

I PS 

4 

20 

5 

I 

5 

21 

6 

I I 

6 

22 

7 

JJ 

7 

30 

« 

NN 

8 

23 

9 

IP 

9 

24 

iu 

K 

li 

J 

12 

M 

U 

MM 

14 

ITEMP 

DO  LOOP  STACK 


SECOND 

SUBSCRIPT 

POINTER  TO 
STATEMENT  NUMBER 
TABLE 

POINTER 
TO  NEST 

POINTER  TO 
SYMBOL  TABLE 

1 

1 

0 

6 

2 

3 

0 

8 

3 

4 

2 

5 

4 

4 

3 

11 

Thei e aie  14  basic  blocks.  The  following  table  indicates 
which  statements  belong  to  which  basic  block. 


BASIC  BLOCK 


1 

1 

3 

4 

5 

6 

7 

8 
y 

iu 

11 

12 

13 

14 


STATEMENT 

4 

5 

6 

7,8 

y ,10 

11,12 

13 

14 

15,16 

17 

18, ly, 20, 21 

22,23,24 

25 

26,27,28 
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BASIC  BLOCK  TABLL 


CATION 

CONTENTS 

LOCA'HON 

CONTENTS 

1 

1 i 1 ^ 1 u 

49 

2009 

2 

3U06 

50 

101  3 

3 

99  8 

51 

998 

4 

1^1  1 1 I u 1 0 1 

3 2 

(TTTrrTTT 

0 

2003 

53 

2002 

b 

2004 

3 4 

2012 

1 

2006 

55 

2002 

b 

2 

36 

2013 

y 

998 

57 

4 

iO 

1 ll  1 1 12|  ll 

58 

8 

1 1 

998 

59 

ui  4 1./4H1 

12 

60 

2002 

1 3 

2006 

61 

2012 

14 

1007 

62 

1014 

15 

3008 

63 

2002 

lb 

7007 

64 

2013 

17 

998 

6 5 

2012 

18 

lll2l"  blol 

6 6 

1002 

19 

2004 

67 

2014 

2U 

2008 

68 

2013 

21 

1009 

69 

1002 

22 

3005 

70 

2012 

2 3 

7009 

71 

2009 

24 

998 

72 

4 

25 

1 2 1 3 1 3 3 1 ol 

73 

9 

26 

2003 

74 

ll  4 1 dll  9 

27 

2009 

75 

2012 

2B 

1010 

76 

1013 

29 

2005 

77 

2012 

3U 

2010 

78 

2009 

31 

2009 

79 

1012 

82 

2003 

80 

7 

33 

3 

81 

I ll  4 1 83l  4 

34 

6 

82 

998 

3b 

1 1 1 

83 

nnnczi 

36 

2010 

84 

99 

37 

1010 

38 

99  8 

J9 

111  jlajU 

4U 

3011 

4 1 

7010 

42 

998 

4 3 

infl.iEn 

44 

2005 

>4  3 

2009 

46 

2011 

47 

1012 

48 

2012 
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SatTiplo  pioqiam  unit  SUHKOUTINK  SORTS  has  2^  statements 
and  14  haste  blocks.  Thet e ate  14  symbolic  names  used  in 
SORTS.  These  14  names  aie  stoied  in  the  symbol  table. 

Assuming  I DTBL { a , ;U0 ) is  used,  all  infoimation  on  the  sym- 
bolic name  IRS,  toi  example,  Is  stoied  in  IDTBL(1,4), 

IDTBL{2,4), ,IDTBL(8,4).  IRS  is  the  fouith  name  stoied 

in  the  IDTBL  aiiay.  Thei e aie  nine  statement  numbers  stoied 
in  the  statement  numbei  table.  All  infoimation  on  statement 
numbei  JO,  foi  example,  is  stored  in  STATRA(1,7)  and  STATRA 
(2,1),  since  statement  numbei  JO  is  the  seventh  statement 
numbei  found.  There  aie  four  DO  loops  stoied  in  the  DO  loop 
stack.  All  infoimation  on  DO  10,  foi  example,  is  stoied  in 
ISTACK(1,2),  ISTACK(2,2),  ISTACK(J,2),  and  ISTACK(4,2),  since 
DO  lo  is  the  second  DO  loop  encountered.  ISTACK(1,2)  contains 
the  intepei  J,  which  points  to  the  third  statement  numbei  in 
the  statement  numbei  table.  The  third  statement  numbei  is  lo, 
which  is  the  terminal  statement  numbei  of  the  DO.  ISTACK(J,2) 
contains  the  inteqei  0,  which  means  this  DO  is  not  contained 
(nested)  in  any  other  DO.  ISTACK(4,2)  contains  the  integer  8, 
which  points  to  the  eighth  name  in  the  symbol  table.  The 
eighth  name  is  NN  which  is  the  induction  vai  iable  foi  this  DO. 

The  14  basic  blocks  compi  ise  statements  4 through  28. 

Basic  block  11,  foi  example,  consists  of  statements  18,ly,2u, 
and  21.  The  basic  block  taole,  I BLOCK  ( 2 5UL) ) , contains  all 
infoimation  on  the  basic  blocks.  IBLOCK  of  1-3  desci  ibes 
basic  block  1,  IBLOCK  of  4-y  desci  ibes  basic  block  2,  etc. 

Basic  block  14,  for  example,  is  desci  ibed  by  IBLOCK  of  o2-58. 
IBLOCK(52)  contains  four  fields.  The  value  in  the  first  field, 
2,  indicates  there  are  two  branches  from  this  block.  The 
value  in  the  second  field,  4,  points  to  the  fouith  DO  loop  in 
the  DO  loop  stack  indicating  that  this  block  is  contained  in 
the  nested  DO  20.  The  value  in  the  third  field,  50,  indicates 
the  location  in  IBLOCK  of  the  next  block.  The  value  in  the 
fouith  field,  7,  points  to  the  seventh  statement  numbei  in  the 
statement  numbei  field  indicating  that  this  block  has  a state- 
ment numbei  of  30.  1BL0CK(53)  and  IBLOCK(55),  each  containing 

the  numbei  2002,  indicate  that  the  vai iable  is  referenced 
( 200 1 ■ 2002;l2  bOO  ) . 2002-2000  gives  the  numbei  2 which  points 
to  the  second  name  in  the  symbol  table,  MUM.  IBLOCK(53)  and 
IBLOCK(bS)  both  having  the  integer  2002  indicate  that  the 
vai  iable  NUM  is  twice  referenced  in  this  block.  IBLOCK(54) 
indicates  that  the  vai  iable  M (2002-2000  = 2,  which  points  to 
M in  the  symbol  table)  is  lefeienced  ( 2000^2002<2500 ) in  this 
block.  IBLOCK(b5)  indicates  that  the  vai  iable  MM  is  referenced 
in  this  block.  IBLOCK(57)  and  IBLOCK(b8),  being  equal  to  4 and 
8,  respectively,  point  to  the  fouith  and  eight  locations  in 
the  statement  number  table  indicating  that  this  block  branches 
to  statement  numbers  20  and  23. 
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1.1. 'il  _COMMON  OlocJ^  pOLOOP^  This  block  contains  info/ mat  ion 
about  the  pioq/am  DO  loop  stiuctu/e. 

1.  I STACK ( 4 , 50 ) - This  inteqe/  ai  i ay  is  constructed  by 
subi out  ines  DO  and  STATNO,  which  process  DO  state- 
ments and  statement  labels,  respectively.  The  array 
stores  the  DO  structure  of  the  program  unit  for  later 
checking.  As  many  as  50  DO  statements  may  be  stored. 
There  are  four  words  that  descr  ibe  the  DO  structure 
for  each  DO  loop: 

Word  1 - Contains  a pointer  to  the  statement 
label  table  entry  (see  COMMON  block  LABELS) 
for  the  terminal  statement  label. 

Word  2 - Used  for  later  processing. 

Word  3 - Contains  a pointer  into  ISTACK  to  the 
DO  which  contains  the  DO  represented  by  this 
DO  loop. 

Word  4 - Contains  a pointer  to  the  symbol  table 
(see  blank  COMMON  storage  - IDTBL)  for  the 
induction  var  iable. 

2.  NSTACK  - The  number  of  DO  loops  in  the  ISTACK  array. 

3.  ILOOP  - Identifies,  for  the  statement  being  pro- 
cessed, which  DO  loop  the  statement  is  contained  in. 

4.  lOVFLW  - Set  to  1 if  the  DO  stack  over  flows;  if  it 
has,  DO  loop  processing  is  terminated. 

2 .2. ^3  COMMON  Block  FLOW. 

1.  IFL  - Flow  analysis  mode  as  input  by  the  user  : 

0 - no  flow  analysis 

1 - moderate  flow  analysis 

2 - full  flow  analysis 

IFL  is  set  to  -1  if  the  flow  analysis  cannot  be  per- 
formed due  to  error(s)  in  the  program  unit. 

2.  IHP  - Repeat  parameter  (set  to  IFL-1)  that  indicates 
the  number  of  times  a statement  number  may  be  re- 
peated in  a given  flow  path. 

. COMMON  Block  FORMAT. 

1.  IDESST  - Location  within  the  input  str  ing  where  the 
scan  for  a format  field  descr  iptor  is  to  start;  set 
by  subroutine  GROUP. 

2.  IDESND  - If  subroutine  DESCRP  finds  a valid  field 
descriptor,  this  is  the  last  location  which  it 
occupies  in  the  str  ing. 
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J.  IGPST  - Location  within  the  input  st  i inq  w'lei  e scan 
toi  a qtoup  of  foimat  field  deset  iptois  is  to  beqin; 
set  by  subroutine  FHMAT. 

4.  IGPND  - If  subroutine  GHOUP  finds  a valid  qroup  of 
field  descr  iptors,  this  is  the  last  location  which 
it  occupies  in  the  str  ing. 

5.  IGRP  - Set  to  1 if  a group  of  field  descr  iptors  is 
valid  and  U otherwise. 

6.  SEPST  - Location  within  the  input  string  where  scan 
for  a format  field  descr  iptor  is  to  begin;  set  by 
subroutine  GROUP. 

7.  SEPND  - If  subroutine  SEPAR  finds  a valid  field 
separator  , this  is  the  last  location  which  it  occu- 
pies within  the  str  ing. 

B.  DIR  - Indicates,  for  subroutine  SEPAR,  which  direc- 
tion to  search  for  a field  separator  (=1  for  search 
forward,  =-l  for  search  backward):  set  by  sub- 
routine GROUP . 

y.  ICOM  - Set  to  1 if  a field  separator  is  a comma 
and  0 if  it  is  not . 

10.  ISEP  - Set  to  1,  0,  or  -1  for  a valid  field  separa- 
tor , not  a field  separator  , or  an  invalid  field 
separator,  respectively. 

2.2.y5  COMMON  Block  FUNC. 


I 

t 

I 

\ 


1.  IFNCRA(5,12)  - This  array  contains  information  about 
function  and  subroutine  references  that  occur  in  the 
statement.  Each  row  of  the  array  represents  a 
different  reference.  The  rows  are  arranged  according 
to  the  order  in  which  the  references  physically  occur 
in  the  statement.  IFNCRA  is  constructed  by  the 
PARSE  subroutine. 

Word  1 - Contains  the  number  of  arguments  encoun- 
ter eo  . 

Words  2-12  - Contain  the  type  and  dimensionality 
of  the  various  arguments.  Each  word  is 
stored  in  the  same  manner  as  it  is  stored  in 
array  INTFAC  of  COMMON  block  LIST.  However, 
for  the  CDC  version.  Bits  55-60  of  each  word 
contain  a value  1 if  the  arguments  in  fields 
1-6,  respectively,  of  this  word  are  in  an 
expression,  and  0 otherwise.  For  the  UNIVAC 
HUB  and  IBM  360,  this  information  is  stored 
in  the  INTFAC  array.  The  I/O  status  is  not 
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dot  ei  nn  ined  in  the  IFNCRA  at  i ay  and  Is 
thotefoie  set  to  zero  foi  each  aiqument. 

2.  MAKGS  - A I unning  count  of  the  numbei  of  enti  ies  in 
lARGS ( 5U ) . 

i.  IARGS(‘3U)  - This  aiiay  keeps  tiack  of  all  vaiiables 
which  occur  in  an  expression  and  notes  the  relation- 
ship of  the  var  iables  to  any  function  references  m 
to  any  implied  DO  loops  within  the  statement.  lARGS 
is  constructed  by  the  parser  subroutines.  Infor- 
mation is  stored  in  20-bit  fields  for  the  CUC  version, 
in  18-bit  fields  for  the  UNIVAC  1108,  and  in  fields 
of  18  b i *•  s (for  ar  ithmetic  and  logical  expressions) 
and  16  bits  (for  I/O  lists)  for  the  IBM  360.  A field 
is  constructed  for  an  ar  ithmetic  or  logical  expression, 
or  for  an  I/O  list. 

For  an  ar  ithmetic  or  logical  expression,  information  is 
stored  in  20-bit  fields  for  the  CDC  version  and  in  18-bit 
fields  for  the  UNIVAC  1108  and  the  IBM  360.  The  CDC  has  three 
fields  per  word,  the  UNIVAC  1108  tv  fields  per  word,  and  the 
IBM  360  one  field  per  word.  For  ari'umetic  and  logical  expres- 
sions,  a field  is  constructed  as  follows: 


UNIVAC  1108 

IBM  360 

CDC 

Bits 

Bits 

1-y 

1-10 

Symbol  table  location  of  var  iable. 

10-12 

11-13 

The  index  of  the  function  or  sub- 
routine of  which  this  var  iable  is  an 
argument.  This  index  points  to  the 
function  or  subroutine  in  IFNCRA(5, 
12).  The  index  is  set  to  zero  if  the 
var  iable  is  not  an  argument  of  a 
function  or  a subroutine. 

13-18 

14-iy 

The  number  of  the  argument  of  the 
function  or  subroutine  which  this 
var  iable  is  associated  with.  Set  to 
zero  if  var  iable  is  not  an  argument. 

20 

Left  blank. 

For  an  I/O  list  information  is  stored  in  20-bit  fields 
for  the  CDC  version,  18-bit  fields  for  the  UNIVAC  1108,  and 
16-bit  fields  for  the  IBM  360.  The  CDC  version  has  three 
fields  per  word  and  the  UNIVAC  1108  and  IBM  360  have  two 
fields  per  word.  For  I/O  lists  a field  is  constructed  as 
foil ows : 
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UN  I VAC  1108 

IBM  160 

CDC 

Bits 

Bits 

Bits 

1-9' 

1-9  *' 

1 - 1 o' 

10-12 

10-11 

11-15 

13-16 

12-16 

15-20 

Symbol  table  location  of 
vat iable . 

Set  to  0,  1,  or  2 depending 
on  whether  the  variable  is  an 
I/O  variable,  subscript  or 
implied  DO  parameter,  or 
implied  DO  index,  respectively. 
If  this  variable  is  an  implied 
DO  index,  this  field  contains 
the  symbol  table  location  of 
the  first  variable  within  the 
expression  which  is  within 
the  implied  DO.  Otherwise 
this  field  is  set  to  zero. 


4.  FNCLOC(5)  - This  array  keeps  track  of  the  symbol  table 
location  of  subroutines  or  functions  referenced  within 
a statement. 

5.  NFUNC  - Number  of  references  to  functions  or  subrou- 
tines within  a statement. 

To  illustrate  the  construction  of  COMMON  block  FUNC,  two 
examples  are  offered.  A symbol  table  and  arrays  IFNCRA, 

FNCLOC,  and  lARGS  for  each  example  are  constructed.  Assume 
that  the  CDC  version  of  AUDIT  is  being  used. 

EXAMPLE  1 


DIMENSION  1(10,10) 

CALL  SUB( I ,SIN(B) , COS ( ABS ( C+D ) -E ) ,J+K) 

Given  the  CALL  SUB  statement  as  above,  the  following 
arrays  are  constructed: 


SYMBOL  TABLE 

IFNCRA 

FNCLOC 

1 

WO HD  2 1 

1 

2 

3 

3 

Row 

1 

4 

IBOOKS 

5 

4 

B 

Row 

2 

1 

Uw)J 

6 

5 

COS 

Row 

3 

1 

fSSI 

6 

ABS 

Row 

4 

1 

lljOjO 

7 

C 

8 

D 

9 

E 

10 

J 

11 

K 
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rt'OI  d i 
Wot  d I 
Wot  d 3 


lARGS  (fO!  GDC) 


i;  1. 

1“  1 

4 : 2- 1 

. Vi4i  1 

( J 4 ; 1 

y : 3 ' 1 

^ 0 1 : 4 . 

1 1 : I ; 4 

Inf oi mat  ion  on  the  CALh  SUB  statement  is  stoi ed  in  the 
symbol  table,  and  the  IFNCRA,  FNCLOC,  and  lARGS  at  lays. 

Symbolic  names  ai e stoied'in  the  symbol  table  in  the  oidei 
of  theii  occui I ence  in  the  CALL  statement.  (Even  though  I 
should  be  fiist  in  the  symbol  table,  since  it  appeals  in  the 
DIMENSION  statement,  foi  simplicity  just  be  concerned  with  the 
oidei  of  names  in  the  CALL  statement.)  Seven  vai  iables  ai e 
used  as  aiguments  within  the  statement.  I,  J , and  K ate 
aiguments  of  SUB,  B is  an  aigument  of  SIN,  C and  D aie  aigu- 
ments of  ABS , and  E is  an  aigument  of  COS.  Thei e is  one 
subioutine  lefeience,  one  inti  insic  function  lefeience,  and 
two  basic  eteinal  function  lefeiences.  Foui  i ows  of  IFNCRA 
aie  theiefoie  used  to  desci  ibe  seven  vai  iables.  Rows  2,  3, 
and  4 each  desci  ibe  the  single  aiguments  of  SIN,  COS,  and 
ABS,  1 espect  ivel y . Row  1 desci  ibes  the  foui  aiguments  which 
aie  vai iables  foi  the  SUB  lefeience.  Foi  Row  1,  Woid  1 con- 
tains the  numbei  of  aiguments  (4).  Vvoid  2 consists  of  foui 
fields  (foi  the  foui  aiguments),  each  field  containing  thi ee 
numbeis.  The  fiist  field  of  Woid  2,  foi  example,  indicates 
that  the  fiist  vaiiable  is  of  integei  type  (4)  and  is  double 
subsci  ipted ( 2 ) . The  FNCLOC  aiiay  contains  pointeis,  to  the 
symbol  table,  of  each  subroutine  and  function  name  lefeienced 
in  the  statement.  FNCLOC(4)=6  indicates  that  the  fourth 
reference  in  the  statement  has  the  symbolic  name  ABS.  The 
lAKGS  array  contains  information  on  each  of  the  seven  variables 
in  the  statement.  The  third  var  iable,  for  example,  is  C and 
is  oescr  ibed  in  the  third  field  of  Word  1.  The  numbei  7 
points  to  C in  the  symbol  table,  the  numbei  4 points  to  the 
fourth  row  in  IFNCRA,  and  the  number  1 indicates  that  C is 
the  first  argument  of  the  reference. 

EXAMPLE  2 


WHITE  (10,10)  A,B, ( (C(  I ,J)  , 1 = 1 ,N)  ,J  = 1 ,N) 


above  WRITE  statement, 


Given  the 
const  1 ucted  : 


SYMBOL  TABLE 

1 A 

2 B 

3 C 

4 I 

5 J 

6 N 


the  following  arrays  are 


64 


“ r 


4 


• ~TWia»ini 


lARGS  (fot  CPC ) 


w Old  1 
v^oi  d 2 
Woi  d J 


Intoimation  on  the  WRITE  sl-atement  is  stoied  in  the 
lARGS  aiiay.  Assume  that  the  variables  encountei  ed  aie 
stoied  in  the  symbol  table  as  in  the  pievious  table.  Thei  e 
aie  nine  occuiiences  of  variables  in  the  I/O  list  that  are 
stoied  in  the  lARGS  aiiay.  Each  word  contains  thiee  fields, 
each  fielci  desciibinsi  a different  variable.  The  second  field 
of  Word  J,  for  example,  describes  the  second  occurrence  of  the 
var  lable  J . The  number  5 points  to  the  vai  iable  J in  the 
symbol  table,  the  number  2 indicates  that  J is  an  implied  DO 
index,  and  the  number  i points  to  the  symbol  table  location  of 
the  fust  vai  iable  (C)  of  the  implied  DO. 

Z.2.yb  COMMON  Block  GIRL. 


1.  NTERMS  - Number  of  terminal  symbols  in  the  qiammai . 
Presently  set  equal  to  IS). 

2-2U.  PLUS  - OPRAND  - The  1 terminal  symbols  used  by  the 
parser  . OPRAND  siqnif  ies  a constant  or  a var  iable. 

2.2.SI7  COMMON  BlocK  GLOBAL. 


1.  NBLK  - The  number  of  enti ies  in  the  COMMON  block 
table  BLKTBL(  200)  . 

2.  NREE  - The  number  of  entries  in  EXTTBL(IOO). 

i.  NSUBS  - The  number  of  entries  in  ISUBS(lOO). 

4.  BLKTBL(200)  - This  array  contains  a list  of  all 
COMMON  blocks  encountered  in  the  program  unit(s) 
being  analyzed.  The  Interface  Definition  file 
location  of  each  COMMON  block  is  stoied  rather  than 
the  name  of  the  block. 

5.  EXTTBL(IOO)  - This  array  contains  a list  of  all 
functions  and  subroutines  which  were  referenced  by 
the  program  unit(s)  being  analyzed.  The  Interface 
Definition  file  location  of  each  function  or  sub- 
routine is  stor  ed  . 

6.  ISUBS(IOO)  - This  array  contains  a list  of  the  pro- 
gram unit(s)  being  analyzed.  The  Interface  Definition 
file  location  of  each  program  unit  is  stoied. 


1 ; o;  u 

2 ; u : u 

0 

0 

TtllT 

5:1:0 

4:2:5 

b ; 1 ! u 

5 ; 2 i 5 

6 ! 1 ; 0 
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2.2.SJ8  COMMON  Block  HL. 


1.  MOL  - GIRL  value  foi  HOL  link  in  GIRL  stiuctuie. 

2.  ACTION  - GIRL  value  foi  ACTION  link  in  the  syntax 
q t aph . 

i.  FUNCl  - GIRL  value  that  indicates  truncation  o£ 
COMPLEX  function. 

4.  FUNC2  - GIRL  value  that  indicates  truncation  of 
DOUBLE  PRECISION  function. 

5.  FUNCi  - GIRL  value  that  indicates  truncation  of 
REAL  f unct  ion . 

6.  LEFT  - GIRL  value  that  holds  inserted  left  paren- 
thesis of  truncation  function. 

7.  RIGHT  - GIRL  value  that  holds  insetted  r ight  paren- 
thesis of  truncation  function. 

8.  STRING  - GIRL  value  that  produces  GIRL  str  ing 
str  uctur  e . 

9.  MAXJ  - Largest  index  of  successfully  parsed  sub- 
st t ing  . 

2. 2. ^9  COMMON  Block  INPOUT. 

1.  NCALL  - The  number  of  statements  in  the  program  unit 
being  analyzed;  set  by  subroutine  BUILD. 

2.  IN  - The  logical  unit  number  of  the  input  device  to 
be  used  for  the  program  unit(s)  being  analyzed.  This 
number  is  input  by  the  user  and  is  5 for  cards  and  7 
for  tape  or  disk. 

i.  lOP  - The  logical  unit  number  of  the  output  device 
for  the  revised  program  unit  (set  to  8). 

2.2.100  COMMON  Block  JL. 

1.  JSTOP  - If  a level  exists,  JSTOP>0.  If  a level  does 
not  exist,  JSTOP=0. 

2.2.101  COMMON  Block  LABELS.  This  block  contains  information 

about  statement  labels. 

1.  STATRA{ 2 , 200 ) - This  array  is  the  statement  number 
table,  created  anew  for  each  program  unit.  As  many 
as  200  statement  numbers  are  stored,  each  statement 
number  being  descr  ibed  by  two  words. 


W o I d 1 - 
Woid  2 - 
field 

field 

field 

field 

field 

f ield 


Contains  the  statement  numbei  . 

Contains  six  fields  of  infoimation 

1 - statement  type,  accotding  to 

F iqui  e 2-U4  . 

2 - 1 if  there  has  been  a statement 

with  this  label  and  0 otherwise. 

3 - 1 if  the  statement  label  has  been 

referenced  and  0 otherwise. 

4 - 1 if  the  label  is  a DO  terminal 

and  0 if  it  is  not  . 

5 - 1 if  the  label  is  on  a complete 

path  and  0 if  it  is  not. 

6 - points  to  the  basic  block  containing 

the  label . 


Fields  1 through  b have  the  following  bit  configurations, 
respectively:  1-b,  7-9,  10-12,  13-15,  and  16-18.  For  the  IBM 

3b0,  field  6 is  bits  19-32;  and  for  the  UNIVAC  1108  and  CDC, 
field  6 is  bits  19-36. 

2.  NLABEL  - The  integer  value  of  the  number  of  statement 
numbers  in  the  statement  number  table. 

2.2.102  COMMON  Block  LIST.  This  block  stores  the  ini  or  mat  ion 
that  resides  in  the  Interface  Definition  file.  The  ISUBLT 
array  lists  the  symbolic  names  of  program  units  and  labeled 
COMMON  blocks  and  stores  information  on  those  names.  The 
INTFAC  array  stores  information  about  arguments  and  Category  1 
COMMON  elements. 


1.  NLIST  - The  number  of  entries  in  the  ISUBLT  array. 

2.  NINTFC  - The  number  of  entries  in  the  INTFAC  array. 

3a.  ISUBLT( 2 , 200 ) - This  array  is  the  CDC  version  of  the 
ISUBLT  array.  It  stores  as  many  as  200  symbolic 
names,  each  name  being  descr  ibed  by  two  words. 

Word  1 - Contains  the  symbolic  name. 

Word  2 - Information  about  that  name. 

Bits  1-6  - (For  subprograms)  The  number  of 
a r g uments . 

(For  Category  1 COMMON  blocks) 

The  number  of  groups  (a  group  is 
a block  of  var  iables  of  the  same 
type) . 

(For  Category  2 and  3 COMMON 
blocks)  A value  of  zero. 

Bits  7-10  - (For  a program  unit).  One  of  the 
following  values: 

0 - User  supplied  (not  in  the 
Interface  Definition  file) 

1 - Subroutine  module 
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2 - Function  module 
i - Ancillary  subprogram 

4 - ANSI  f unct  ion 

5 - Main  pr  og r am 

6 - Extraordinary  subroutine 
(For  labeled  COMMON  blocks)  One 
o£  the  following  values: 

7 - Category  1 COMMON  block 
b - Category  2 COMMON  block 
9 - Category  3 COMMON  block 

Bits  11-13  - Function  type  (1  for  real,  2 for 
complex,  3 for  double  precision, 

4 for  integer,  5 for  logical).  If 
the  symbolic  name  is  a COMMON  block, 
a zero  is  stor  ed  . 

Bit  14  - Set  to  1 if  a subprogram  has  a vari- 
able number  of  arguments  and  0 
ot  her  w ise  . 

Bits  15-30  - Maximum  size  of  blank  COMMON  (if 
any)  . 

Bits  31-60  - Points  to  the  beginning  location 
in  the  INTFAC  array,  where  infor- 
mation on  the  arguments  or  Category 
1 COMMON  is  desct  ibed . 

3b.  ISUBLT( 3 , 200 ) - This  array  is  the  UNIVAC  1108  version 
of  the  ISUBLT  array.  Three  words  are  used  to  describe 
a symbolic  name.  The  first  two  words  are  the  same  as 
in  3a,  except  that  Bits  15-36  store  the  size  of  blank 
COMMON.  Word  3 contains  the  pointer  into  the  INTFAC 
ar  r ay . 

3c.  ISUBLT( 4 , 200 ) - This  array  is  the  IBM  360  version  of 
the  ISUBLT  array.  Four  words  are  used  to  describe 
a symbolic  name.  Words  1 and  2 contain  the  symbolic 
name.  Word  3 is  the  same  as  Word  2 of  the  CDC  ver- 
sion, except  that  Bits  15-32  store  the  size  of  blank 
COMMON.  Word  4 contains  the  pointer  into  the  INTFAC 
array. 

4a.  INTFAC(300)  - This  array  is  the  CDC  veision  of  the 
INTFAC  array.  It  contains  information  about  sub- 
routine argument  lists  and  Category  1 COMMON  blocks. 

For  subprograms,  arguments  are  stored  six  fields  per 
word,  each  field  of  the  following  form. 

Bits  1-3  - Argument  type  (1  for  real,  2 for  com- 
plex, 3 for  double  precision,  4 for  integer, 

5 for  1 og  ical ) 

Bits  4-6  - Argument  dimensionality  - (0,1,2,  or  3 
for  0,1,2,  or  3 subscripts) 
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Bits  7-y  - Atqument  i /O  status  (0  foi  output,  1 fot 
input  and  outpu*",  2 for  input) 

Foi  Category  1 COMMON  blocks,  groups  are  stored  three 
fields  per  word,  each  field  of  the  following  form: 

Bits  1-17  - Size  of  group 

Bits  18-20  - Type  of  group  (1  for  real,  2 for  complex, 
3 for  double  precision,  4 tor  integer,  5 for 
1 og ical  ) . 

4b.  INTFAC(50U)  - This  array  is  the  UNIVAC  1108  version 
of  the  INTFAC  array. 

For  subprograms,  arguments  are  stored  four  fields  per 
word,  each  field  of  the  following  form: 

Bits  1-3  - Argument  type 

Bits  4-6  - Argument  dimensionality 

Bits  7-8  - Argument  I/O  status 

Bit  y - Set  to  1 if  the  argument  is  in  an  expression 

and  0 if  not  (For  CDC  version,  this  value  is 
stored  in  the  IFNCRA  array). 

For  Category  1 COMMON  blocks,  groups  are  stored  in  two 
fields  per  word,  each  field  of  the  following  form: 

Bits  1-15  - Size  of  group 
Bits  16-18  - Type  of  group 

4c.  INTFAC(6U0)  - This  n r ay  is  the  IBM  360  version  of 
the  INTFAC  array. 

For  subprograms,  arguments  are  stored  three  fields  per 
word,  each  field  of  the  same  form  as  in  4b. 

For  Category  1 COMMON  blocks,  groups  are  stored  one  field 
per  word,  each  field  of  the  same  form  as  in  4b. 

2.2.103  COMMON  Block  LOGIC. 


1.  LOG  - Set  to  1 if  a logical  operator  or  constant  is 
found  and  0 otherwise. 

2.  LOGST  - Location  in  input  str  ing  where  search  for 
logical  operator  or  constant  is  to  start. 

2.2.104  COMMON  Block  LVARGS . 

1.  IFUNC  - The  1 ink  of  the  tr  iple,  also  known  as  the 
function.  It  must  be  a random  number  as  defined 
by  LVGRN. 


69 


2.  lARG  - The  source  node  of  the  triple,  also  known  as 
the  arqument  of  the  function.  It  must  be  a random 
number  as  defined  by  LVGRN. 

3.  lADD  - The  location  (address)  of  the  triple  in  the 
bu  f f e r . 

4.  IPOS  - The  position  from  the  top  (if  positive)  or 
bottom  (if  neqative)  of  the  multi-value  list  into 
whrch  the  new  value  will  be  placed.  If  ITYP  is  speci- 
fied, only  that  type  of  value  is  counted  when  deter- 
mininq  the  position  in  the  list. 

5.  ITYP  - 'Die  type  of  value  to  be  searched  for  in  a 
multi-vaiue  list.  It  is  used  for  destructive  and  non- 
destructive insertions  and  may  have  the  following 
values : 

-1  - Delete  the  entire  function 

0 - Random  number 

1 - Integer  data 

2 - Hollerith  data 

3 - No  specified  type 

6.  IVAL  - The  retrieved  value.  However,  if  the  value 
cannot  be  found,  IVAL  is  et  to  -1. 

7.  LSTHED  - The  location  of  the  head  of  the  multi-value 
list,  otherwise, 

0  - if  no  list  is  round 
-1  - if  a single  valued  list  is  found 

8.  NVAL  - The  number  of  values  (up  to  ten)  to  be  inserted 
in  the  graph. 

9.  IDSTRY  - Indicates  the  type  of  insertion  to  be  made 
according  to  the  followii  3 values: 

0 - Normal  insertion  - the  triple  is  always 

placed  at  the  end  of  the  (null)  list. 

1 - Destructive  insertion  - the  IPOS^  ’ member  of 

the  ITYP-t' type  from  the  top  or  bottom  of  a 
list  (depending  on  the  sign  of  IPOS)  is 
replaced  by  the  contents  of  IVALS(l). 

2 - Nondestructive  insertion  - the  contents  of 

IVALS(l)  are  wedged  into  the  list,  making 
the  new  value  the  IPOS^^’member  of  the  ITYPi*^ 
type  from  the  top  or  bottom  of  the  list 
(depending  on  the  sign  of  IPOS). 

10.  IVAIiS(lO)  - The  values  or  sink  nodes  to  be  insetted; 
they  may  be  any  of  the  following  types: 
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Random  number  as  def  Lned  by  LVGRN 
Intecjei  data  (up  to  2**16) 

Holler  1 1 h data 

11.  ITYPl(lO)  - A type  descr  ipt ion  for  each  value  in 
IVALS(i)  to  be  inserted  accoroinq  to  the  following 
va 1 ues : 

U - Random  number 

1 - Integer  data 

2 - Continuing  Holler  ith  data 

d - The  only  or  final  cell  of  a Holler  ith  data 
St  r ing 

12.  NSKIP  - Saved  index  defeat  switch.  If  NSKIP=1,  thf> 
saved  index  operation  is  skipped.  Otherwise  the  savf^d 
index  is  in  effect. 


2.2.1U5  COMMO.r^  Block  LVFLAG.  This  COMMON  block  contains 
integers  which  are  used  as  masks  to  extract  and  insert  infor- 
mation f r orTi  COMMON  block  LVVTR4  . 


2.2.1U6  COMMON  Block  LVRAND.  This  COMMON  block  is  used  in 
the  computation  of  random  numbers  for  the  nodes  on  the  graph. 

2 . 2 . 1 U 7 COMMON  Blocks  LVTABI  and  LVVSEQ.  These  COMMON  blocks 
are  generated  by  the  GIRL  software  and  are  not  used  by  AUDIT. 

2.2.10b  COMMON  Block  hVVTRl . 


1.  MEMSZE  - GIRS  memory  size  (set  to  1000).  This  value 
is  set  at  the  time  the  graph  is  created  and  can  only 
be  changed  by  recreating  the  graph. 

2.  REGASP  - If  a location  for  a tr  iple  is  computed  and 
that  location  is  already  in  use,  this  value  points 
to  the  next  available  location  where  the  tr  iple  may 
be  stor  ed  . 

3.  NODSPC(IOOO)  - For  each  tr  iple  (there  may  be  as 
many  as  1000),  one  of  three  possible  items  is  stored 
in  each  1 ocat  ion : 

a.  Source  node  of  a single-value  list 

b.  Source  node  of  a multi-value  list 

c.  Sink  node  of  a value  on  a multi-value  list. 


2.2.10^  COMMON  Block  LVVTR2 . 


1,  hSTSPC(lOOO)  - For  each  triple  (there  may  be  aS  many 
as  1000),  the  sink  node  of  a single-value  list  is 
St  or  ed . If  the  list  is  a mu  1 1 i - va 1 ue  list,  the 
pointer  to  the  next  item  in  the  list  is  stored.  The 
head  of  the  list  points  to  the  first  sink  node,  and 
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t-he  last  sink  node  points  back  to  the  head  of  the 
list;  thus  a ciiculai  sttuctuie  is  cieated. 

^ ■ HU  COMMON  Block  LVVTR3. 

1.  LNKSPC(IOUO)  - Foi  each  tt  Lple  (of  as  many  as  lOOU), 
the  conflict  list  pointei  is  stoied.  All  heads  of 
lists  which  hash  to  the  same  location  are  linked  to- 
gether on  a circular  list.  If  an  entry  has  no  con- 
flicts it  points  to  itself. 

2.1. 111  COMMON  Block  LVVTR4 . 

1.  FLGSPC ( 1 UOU ) - For  each  tr  iple  (of  as  many  as  1000), 
five  flays  are  stored; 

Bit  1 - 1 if  head  of  a multi-value  list 

0  if  not 

Bit  2 - 1 if  cell  is  in  working  space 

0 if  cell  is  available 

Bit  3 - 1 if  value  is  on  a multi-value  list 

0 if  not 

Bit  4-5  - left  blank 

Bit  6 - 1 if  head  of  conflict  list 

U if  not 

Bit  7-8  - 0 if  random  number 

1 if  integer  data 

2 - if  continuing  Holler  ith  str  ing 

3 - if  only  or  final  Holler  ith  str  ing 

2.2.112  COMMON  Blocks  LVVTR5,  LVVTR6 , LWTR7,  and  LvVTRS. 

These  COMMON  blocks  are  generated  by  the  GIRL  software  and  are 

not  used  by  AUDIT. 

2.2.113  COMMON  Block  NEED. 

1.  START  - Beginning  state. 

2.  ASSOC  - GIRL  pseudo- r andom  variable  for  associate. 

3.  LEVEL  - GIRL  pseudo-random  var  iable  for  level. 

4.  STOP  - GIRL  pseudo-random  variable  for  a permissable 
final  state.  Also  a stop  link  to  a stop  state  is 
per  m issable . 

14  COMMON  Block  NEEDS. 

1.  STJ  - The  value  of  the  token  (in  input  string) 
presently  being  examined. 

2.  JSTACK  - Index  which  points  to  a location  in  the 
St  dck  . 
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R - Piesent  state  in  the  graph. 


4.  JAS  - Index  of  last  associate  taken. 

5.  J - Index  of  present  token  in  the  input  string. 

6.  JLAST  - Index  to  the  beginning  of  a primary,  which 
is  a parenthesized  expression. 

7.  RTEMP  - Value  of  last  state  of  the  graph,  in  case  of 
immediate  need  to  back  up. 

8.  STACK(400)  - Array  which  holds  all  the  nodes  visited 
as  well  as  other  information  which  is  necessary  in 
order  to  back  up  (i.e.,  recognize  a context  free 
language ) . 

Bloc k_  NOPAR. 

1.  NOPAR  - Stack  variable  used  to  keep  track  of  recur- 
sive functions. 

2.  NDEP  - Same  as  NOPAR. 

3.  NDEPTH  - Function  counter. 

4.  NFLAG  - Stack  variable  for  use  in  I/O  list  processing. 

• IJA-  i_qc_k_  ,ntj_me;s_^ 

1.  NTiMES  - Flag  to  indicate  that  the  syntax  graph  has 
been  read  from  disk  to  core. 

2.  I - If  the  syntax  graph  runs  out  of  storage  space 
while  parsing  a statement,  I indicates  how  far  the 
statement  has  been  parsed. 

Block  RA^yiO.-. 

1.  IREAL  - Set  to  1 if  a real  number  is  found  and  0 
otherwise . 

2.  IRELND  - The  last  location  of  a character  string 
representing  a real  number. 

3.  IP  - If  a character  string  is  to  be  tested  to  see  if 
it  is  a real  number,  this  value  points  to  the 
beginning  location  of  the  string. 

2.2 .118  COMMON  Block  STFUNC. 

1.  NSTFNC  - The  number  of  entries  in  the  ISTFNC  array. 


73 


2 


2.  ISTFNC(IO)  - This  ai  r ay  contains  symbol  table 

locations  of  all  statement  functions  in  the  piogtam 
unit. 

2.2.119  COMMON  Block  STRING. 

1.  NTVPE  - Indicates  the  type  of  an  expiession  accoiding 
to  the  following  values: 

1 - Ai  i thmet  ic 

2 - Log  ical 

3 - I/O  list 

2.  NSTR  - The  number  of  language  elements  in  STR. 

3.  STR(500)  - Encoded  expression  for  a character  string 
(see  SUBROUTINE  EXPR). 

2.2.12U  COMMON  Block  TYP. 

1.  NARRAY  - The  number  of  subscripts  in  an  array. 

2.  TYPEl  - The  cype  of  the  pr  esent  opr  and  of  the  present 
oper  ator  . 

3.  TYPE2  - The  type  of  the  first  opr  and  of  a binary 
operator.  TYPEl  will  hold  the  type  of  the  second 
opr  and . 

4.  ERRFLG  - The  value  of  .TRUE,  if  a syntactic  error  has 
occurred.  The  value  of  .FALSE.,  otherwise. 

2.2.121  COMMON  Block  VAR. 

1.  VF0R(15)  - This  array  contains  the  display  code  for 
output  of  an  incorrect  input  str  ing. 

2.  NUMCHR  - The  number  of  characters  presently  placed 
in  the  last  used  word  of  VFOR. 

3.  NCHRP  - The  final  number  of  tokens  (including  inserted 
functions  and  parens)  in  the  transformed  input  string. 

4.  CHAR  - The  display  code  of  input  characters. 

5.  NDICT  - The  equivalent  value  for  input  characters. 
(-1_NDICT  --18) 

2.2.122  COMMON  Block  WASTE.  This  is  a dummy  COMMON  block 

used  to  store  local  arrays. 


7 4 


4 


SECTION  J. 


INPUT/OUTPUT  DESCRIPTIONS 


3.1  Gcnei al  Desci  Lptlon.  The  inputs  and  outputs  of  the 
AUDIT  system  aie  of  thiee  types: 

1.  Catd,  tape,  and/oj  disk  input  fuinished  by  the  user. 

2.  Disk  input  and  output  which  is  of  no  diiecr  concei  n 
to  the  usei  . 

3.  Pt  inted  output  that  is  of  direct  concei  n to  the  usei  . 
The  inputs  and  outputs  of  the  AUDIT  system  that  fall 
into  these  thiee  categoi  ies  are  desci  ibed  in  the 
following  section. 

3.2  Char actei  ist  ics , Organization,  and  Detailed  Description 

of  System  Data. 

3.2.1  User  I nput . Certain  items  must  be  furnished  by  the  user 
each  time  the  AUDIT  system  is  executed: 


1 . An  opt  ions  car  a 

2.  The  software  to  be  examined 

3.  The  Interface  Definition  file 

4.  The  syntax  graph  file 

5.  A package  of  vai  iable  precision  functions  for  each 
truncation  operator  (bit  con  f ig  ui  a t ion  ) desired. 
(Needed  only  if  the  vai  iable  precision  mode  is 
selected . ) 


3. 2. 1,1  Options  Card.  The  first  card  in  the  user  's  input 
deck  is  the  options  card,  always  supplied  as  card  input.  If 
the  software  to  be  examined  is  on  tape  or  disk  and  the  vai iable 
precision  mode  has  not  been  selected,  the  options  card  will  be 
the  only  card  input.  The  options  card  is  punched  in  the  format 
( 1 1 , 3X , 1 1 , 3X , 1 1 , 3X  , 1 1 ) and  is  constructed  as  follows: 

1.  Column  1 indicates  the  mode  of  operation: 

1 - Audit  mode  only,  or  both  the  audit  mode  and  the 

variable  precision  mode. 

2 - Audit  mode  and  roll  call  mode  (subprogram  to  be 

examined  does  not  contain  a reference  to  utility 
module  HOLCOL) . 

3 - Audit  mode  and  roll  call  mode  (subprogram  to  be 

examined  contains  a reference  to  utility 
mod u 1 e ROLCOL ) . 


Column  5 indicates 


the 

sof  twai e 

to 

be 

5 - 

Sof  t wa 1 e 

is 

on 

7 - 

Sof  t war  e 

is 

on 

1106) 

2 - 

Sof  twai e 

is 

on 

the  input  log  ical 

exam  i ned : 

cards 

tape  or  disk  ( For 
tape  or  disk  (For 


unit  number  for 

CDC  and  UNIVAC 
IBM  360) 


3.  Column  9 indicates  whethe/  ot  not  the  flow  analysis 
mode  is  to  be  used: 

0 - No  flow  analysis 

1 - Model  ate  flow  analysis 

2 - Compt ehens  i ve  flow  analysis 

4.  Column  13  indicates  whether  oi  not  intrinsic  and 
basic  external  function  names  are  to  be  checked  for 
misuse  (See  SESC0MPSPEC3 , Section  8): 

U - Do  not  check  names 
1 - Check  names 

The  AUDIT  system  always  performs  the  audit  mode.  The 
var  lable  precision  or  roll  call  mode  may  also  be  selected 
(Column  1).  A value  of  1 in  Column  1 indicates  one  of  two 
possible  actions:  (1)  audit  mode  only,  ot  (2)  audit  mode  and 

var  lable  precision  mode.  The  AUDIT  system  distinguishes 
between  these  two  options  by  the  additional  control  cards  and 
input  cards  for  the  vat  iable  precision  mode.  An  entire  execu- 
table program  (main  program,  all  subprograms,  and  data)  must 
be  submitted  when  the  vat  iable  precision  mode  is  selected. 

No  additional  software  (other  than  the  one  executable  program) 
may  be  examined  by  the  var  iable  precision  mode.  The  roll  call 
mode  is  only  used  to  examine  the  toot  program  unit  of  a module. 
Main  programs,  ancillary  subpt  og  r am.s  , ot  extraordinary  sub- 
routines should  not  be  examined  by  the  roll  call  mode. 

3. 2. 1.2  Software  To  Be  Examined.  The  software  to  be  examined 
is  input  to  the  AUDIT  system;  it  must  be  on  cards,  tape,  ot 
disk,  and  it  may  be  on  only  one  of  the  three  mediums.  If  the 
software  is  on  cards,  it  must  immediately  follow  the  options 
card,  and  a value  of  5 must  be  punched  in  Column  5 of  the 
options  card.  If  the  software  is  on  tape  or  disk  (must  be  in 
source  format),  the  tape  or  disk  involved  must  be  identified 
as  logical  unit  number  7 ot  2,  and  a value  of  7 ot  2 must  be 
punched  in  Column  5 of  the  options  card. 

If  the  var  iable  precision  mode  is  selected,  only  one 
executable  program  (main  program,  subprograms,  and  data)  may 
be  input.  If  the  toll  call  mode  is  selected,  only  the  toot 
program  unit  of  a module  may  be  input.  Only  one  main  program 
may  be  input  per  execution.  There  is  a limit  to  the  number 
of  subprograms  that  may  be  inp.^t  pf'i  execution.  This  limit 
depends  on  the  complexity  of  the  subprograms.  A reasonable 
upper  limit  on  the  number  of  subprograms  input  pet  execution 
is  1 U . 

3. 2. 1.3  Interface  Definit'^n  File.  Before  any  software  can 
be  examined,  the  Interface  Definition  file  must  be  constructed 
by  auxiliary  program  SESLlST  (see  Section  4.4.1).  The  Irtei- 
face  Definition  file  is  an  unformatted  file  wh  ;h  is  read  from 
logical  unit  4 by  AUDIT'S  main  program  and  is  stored  in  arrays 
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ISURI/r  and  INTFAC  of  COMMON  block  LIST.  The  file  contains 
information  about  all  program  units  and  COMMON  blocks  that 
may  be  referenced  by  the  software  being  examined. 


For  root  program  units  of  modules,  main  programs, 
ancillary  subprograms,  ex t r aord i na r y subroutines,  intrinsic 
and  basic  external  functions,  and  other  external  subprograms, 
the  Interface  Definition  file  contains  information  on  the 
argument  list  (if  any)  of  the  program  unit  and  other  appro- 
priate information.  The  file  also  contains  information  about 
all  blank  COMMON  and  labeled  COMMON  blocks. 

The  Interface  Definition  file  consists  of  two  parts: 

(1)  the  basic  Interface  Definition  file,  and  (2)  the  user 
supplied  Interface  Definition  file.  The  basic  Interface 
Definition  file  consists  of  information  on  the  intrinsic  and 
basic  external  functions,  and  the  labeled  COMMON  block  SESCOM. 
This  basic  file  (listed  in  Appendices  B,  C,  and  D)  is  con- 
sidered to  contain  information  that  may  be  referenced  by  all 
software  produced  for  the  SESCOMP  system.  Each  time  new  soft- 
ware is  to  be  examined,  the  user  supplied  file  is  constructed 
for  the  specific  software.  The  user  supplied  file  should  not 
contain  any  information  that  is  present  in  the  basic  file. 

This  user  supplied  file  is  then  added  to  the  basic  file  to 
make  up  the  Interface  Definition  file  for  the  software  to  be 
examined.  A maximum  of  2U0  symbolic  names  may  be  entered  in 
the  file. 

As  stated  before,  the  Interface  Definition  file  is 
created  by  the  independent  program  SESLIST.  The  information 
that  constructs  the  file  is  punched  on  cards.  SESLIST  reads 
the  cards,  packs  the  card  images,  and  writes  them  out  unfor- 
matted onto  logical  unit  4.  This  file  is  saved  and  used  as 
an  input  file  for  the  AUDIT  system.  The  user  must  rerun 
SESLIST  each  time  a change  in  the  file  is  necessary.  The  old 
file  is  discarded  and  the  new  one  is  savea  . While  operating 
under  the  audit  mode,  each  reference  to  a program  unit  or 
labeled  COMMON  block  is  checked  for  consistency  against  the 
Interface  Definition  file.  If  a program  unit  or  labeled 
COMMON  block  is  not  in  the  file,  the  name  and  its  associated 
information  is  added  to  the  ISUBLT  and  INTFAC  arrays  (COMMON 
block  LIST).  Any  subsequent  reference  to  that  program  unit 
or  labeled  COMMON  block  is  then  checked  for  consistency  with 
the  first  reference. 

The  user  supplied  file  consists  of  each  reserved  sym- 
bolic name  used  by  the  software  to  be  examined  (excluding 
those  names  already  in  the  basic  file).  There  will  be  at 
least  one  card  of  information  associated  with  each  name.  For 
subroutine  and  function  subprograms  with  arguments  and 
Category  1 labeled  COMMON  blocks,  additional  cards  will  be 
needed.  Subroutine  and  function  subprograms  without  arguments. 


77 


J 


* 


Category  2 and  J labeled  COMMON  blocks,  or  blank  COMMON  will 
each  have  only  one  card  associated  with  it. 

SESLIST  requires  at  least  one  input  card  for  each  sub- 
program and  main  program.  This  card  is  constructed  as  follows: 


Col umns 
Col umns 


Column  11 


Column  13 


Columns  15-20 


The  symbolic  name  (left  justified) 

The  number  of  arguments  (right  justi- 
fied); (if  none,  punch  a zero  in 
Column  9) 

Function  type  (if  the  program  unit  is  a 
function  subprogram) 

1 - Real 

2 - Complex 

3 - Double  Precision 

4 - Integer 
Log  ical 

the  program  unit  is  not  a function 
subprogram,  punch  a zero) 

The  class  of  the  symbolic  name: 
Subroutine  module 
Funct  ion  module 
Ancillary  subprogram 

Intrinsic  or  basic  external  function 
Main  program 

Extraordinary  subroutine 
size  of  blank  COMMON,  if  any  (right 


a - 
(If 


1 - 
2 - 

3 - 

4 - 

5 - 

6 - 
The 


justified) 


If  the  program  unit  doesn't  have  any  arguments,  only  the 
above  card  is  needed  to  describe  the  symbolic  name.  Otherwise, 
more  cards  are  needed  to  describe  the  arguments.  Each  argu- 
ment requires  a 4-column  field,  with  as  many  as  20  fields  per 
card.  If  there  are  more  than  20  arguments,  a second  card  is 
required;  if  there  are  more  than  40  arguments,  a third  card  is 
required,  and  so  on.  A maximum  of  63  arguments  is  permitted. 
The  fields  are  ordered  left  to  right  in  the  same  order  as  the 
arguments.  A field  is  constructed  as  follows: 


Column  1 


Column  2 


Column  3 


The  argument  type: 

1 - Real 

2 - Complex 

3 - Double  Precision 

4 - Integer 

5 - Log  ical 

The  dimensionality  of  the  argument: 

0 - Non-subscr ipted  simple  variable 

1 - Single-subscripted  array 

2 - Double-subscripted  array 

3 - Triple-subscripted  array 
Argument  I/O  status: 

0 - Output 
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Column  4 


1 - Input  and  output 

2 - Input 

Blank  (seives  as  a sepai atoi  between 
f i e 1 d s ) 

Foi  example,  utility  module  SESPLl  is  desci ibed  by  the 
tol lowing  two  caids: 

(Catd  1)  SESPLl  3 U 1 

(Caid  2)  4U2  4U2  402 


SESLIST  lequiies  at  least  one  input  caid  £oi  each 
labeled  COMMON  block.  This  catd  is  constiucted  as  follows: 


Columns  1-6 
Column  y 


Column  11 
Column  13 


Columns  15-20 


The  symbolic  name  (left  justified) 

( Fot  Categoiy  1)  The  numbet  of  groups 
contained  in  the  block,  a group  being 
a set  of  consecutive  words  of  the 
same  t ype . 

(Fot  Category  2 and  3)  Left  blank 
Always  zet  o 

The  category  of  labeled  COMMON: 

7 - Category  1 labeled  COMMON  block 

6 - Category  2 labeled  COMMON  block 

y - Category  3 labeled  COMMON  block 

(Fot  Category  1)  The  size  of  the  block 
(tight  j ust  if  led  ) 

(Fot  Category  2 and  3)  Left  blank 


Category  2 and  3 labeled  COMMON  blocks  do  not  requite 
additional  cards;  Category  1 labeled  COMMON  blocks  requite 
additional  cards  describing  the  structure  of  the  blocks.  The 
additional  Category  1 cards  ate  constructed  as  follows: 


Each  group,  a set  of  consecutive  words  of  the  same  type, 
requites  a field  of  eight  columns.  As  many  as  ten  8-column 
fields  may  be  punched  pet  catd,  with  additional  cards  used 
as  needed.  The  fields  ate  ordered  left  to  t ight  in  the  same 
order  as  the  groups.  Each  8-column  field  is  constructed  as 
foil ows : 


Columns  1-6  Numbet  of  words  in  the  .group  (r  ight 
justified).  A double  precision  or 
complex  vat  iable  is  counted  as  two 
wot  ds . 

Column  8 Type  of  the  group: 

0 - Hollerith 

1 - Real 

2 - Complex 

3 - Double  precision 

4 - Integer 

5 - Log ica 1 
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For  example,  the  description  jf  the  Category  1 labeled 
COMMON  block  SESCOM  is  punched  on  two  cards,  as  follows: 

(Card  1)  SESCOM  27  25 

(Card  2)  13  0 12  4 

When  organizing  the  input  cards  for  SESLIST,  the  card(s) 
that  describes  the  arguments  or  the  groups  must  immediately 
follow  the  symbolic  name  the  card(s)  is  associated  with. 

Although  there  is  no  prescribed  order  for  the  symbolic  names, 
an  alphanumeric  arrangement  is  usually  convenient.  Such  an 
arrangement  simplifies  the  retrieval  of  a reserved  name  by 
the  user.  The  file  that  is  constructed  by  program  SESLIST  must 
be  saved  (catalogued)  as  a tape  or  disk  file.  Each  time  the 
AUDIT  system  is  executed,  this  Interface  Definition  file  must 
be  input  to  the  system. 

3. 2. 1.4  Syntax  Graph.  The  syntax  graph  is  a plex  data 
structure  which  contains  the  syntax  for  all  arithmetic  and 
logical  expressions  and  I/O  lists.  It  is  constructed  by  program 
GRAPH,  which  reads  the  graph  from  punched  cards,  and  then  packs 
and  writes  out  the  information  as  an  unformatted  file  onto 
logical  unit  4.  Whenever  one  of  the  expressions  or  lists  is 
encountered  by  the  AUDIT  system,  the  structure  of  the  expression 
or  list  is  checked  against  the  graph  for  validity.  The  graph  is 
an  unformatted  file  which  is  read  by  the  parser  subprograms 
from  logical  unit  19  and  is  stored  in  COMMON  blocks  GIRL, 

LVTABL,  LVVSEQ,  LVVTRl,  LVVTR2 , LVVTR3,  and  LVVTR4 . The  syntax 
graph  file  remains  constant.  It  is  constructed  just  once  and 

is  then  reused  whenever  the  AUDIT  system  is  executed.  The  user 
need  not  concern  himself  with  the  data  to  construct  the  file. 

The  data  has  already  been  constructed  and  will  not  change.  The 
user  need  only  create  the  file  by  running  program  GRAPH.  He 
then  saves  the  file  as  a tape  or  disk  file. 

3. 2. 1.5  Variable  Precision  Functions.  When  AUDIT  is  operating 
under  the  variable  precision  mode,  a package  of  variable  pre- 
cision functions  must  be  input  for  each  bit  configuration 
desired.  The  following  three  function  subprograms  (a  package) 
are  needed  for  each  bit  configuration: 

1.  REAL  FUNCTION  QlREAL 

2.  DOUBLE  PRECISION  FUNCTION  QlDPRE 

3.  COMPLEX  FUNCTION  QlCOMP 

The  user  may  simulate  word  lengths  of  30  to  40  bits  for  the 
CDC  6000,  24  to  31  bits  for  the  IBM  360,  and  30  to  35  bits 
for  the  UNIVAC  1108.  Each  processor  uses  a unique  set  of 
packages . 

3.2.2  AUDIT-Gener ated  I/O.  The  AUDIT  system  generates 
several  temporary  disk  files  which  are  used  at  various  stages 
of  the  AUDIT  execution.  These  files  are  of  no  direct  concern 
to  the  user . 
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1.2.2.1  Rev L sea  Ft  out  am  Files.  Each  time  the  audit  mode  Is 
executed,  the  softwate  belnq  examined  is  levlsed  and  the 
levised  piogiam  tesides  on  logical  unit  8.  Thete  ate  two 
diLfeient  kinds  oC  levised  piogtam  files  generated. 

1.  If  the  toll  call  mode  is  not  selected,  all  at  ithmetic 

operations  { + \ * ) that  involve  teal,  complex, 

and  double  precision  vat  iables  ot  constants  ate 
changed  into  references  to  the  vat  iable  precision 
function  subprograms  QIREAL,  QICOMP,  and  QlDPRE.  For 
example,  A=B+C  is  transformed  into  A=Q1 REAL ( B+C ) , 
assuming  A,  B,  and  C are  teal.  If  the  vat  iable  pre- 
cision mode  is  selected,  the  revised  program  file  is 
used  to  perform  the  vat  iable  precision  calculations. 
Otherwise,  the  file  is  not  used. 

2.  If  the  toll  call  mode  is  selected,  all  references  to 
function  and  subroutine  modules  ate  changed  to  ref- 
erences to  subroutine  ROLCHK,  and  all  READ  statements 
ate  omitted.  These  revisions  ate  performed  for  a 
single  subprogram.  The  main  program  ROLCAL  is  added 
to  the  file.  This  file  is  then  used  to  execute  the 
toll  call  mode. 

1.2.2.2  AUDIT  Module  List.  The  AUDIT  module  list  is  generated 
only  if  the  toll  call  mode  is  selected.  The  list  consists  of 
function  and  subroutine  module  references  encountered  dut  ing 
the  audit  mode.  The  list  is  contained  on  an  unformatted  file 
which  tesides  on  logical  unit  9.  It  is  used  by  subroutine 
CMPARE  to  vet  ify  that  all  of  the  referenced  modules  were  also 
referenced  in  the  SESCOMP  toll  call  mode. 

j.2.2.3  ROLCHK  Module  List.  The  ROLCHK  module  list  is 
generated  dut  ing  execution  of  the  toll  call  mode.  The  list 
consists  of  all  modules  referenced  in  the  SESCOMP  toll  call 
mode.  It  is  an  unformatted  file  which  tesides  on  logical  unit 

3.  This  file  is  constructed  by  subroutine  ROLCHK.  It  is  used 
by  subroutine  CMPARE  to  compare  with  the  AUDIT  module  list  to 
insure  that  the  same  names  ate  on  both  lists. 

3.2.3  Roll  Call  Output  Files.  The  toll  call  output  files 
contain  the  contents  of  the  SESCOMP  output  devices  X,  Y,  and 
Z,  which  ate  created  by  the  simulated  execution  of  the  program 
unit  being  examined.  The  contents  of  output  devices  X,  V, 

and  Z are  written  on  logical  units  13,  14,  and  1 3 , respectively. 
These  devices  contain  the  Module  Identification  Fields,  use 
counts,  and  buffer  tracing  information  pertinent  to  the  simu- 
lated SESCOMP  roll  call  modes.  The  user  may  display  the  con- 
tents of  these  files  at  the  completion  of  execution,  assuming 
the  roll  call  mooe  has  been  selected. 

3.2.4  Printed  Output.  Each  program  unit  of  the  software  being 
examined  has  its  own  pr  inted  output.  After  the  pr  intout 
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associated  with  all  program  units  has  been  generated,  a global 
reference  table  is  printed  which  contains  information  on  all 
the  program  units  processed.  A description  of  the  printout 
associated  with  each  program  unit  follows. 

AUDIT  prints  each  statement  of  the  software  being  pro- 
cessed together  with  a diagnostic  message  if  any  intrastate- 
ment errors  have  been  found.  Each  assignment  or  CALL  state- 
ment that  contains  a real,  double  precision,  or  complex 
operation  is  transformed  to  include  the  references  to  QlREAL, 
QlDPKE,  and  QICOMP,  regardless  of  whether  or  not  the  variable 
precision  option  was  selected.  If  the  roll  call  mode  has 
been  selected,  each  module  reference  is  transformed  into  a 
reference  to  subroutine  ROLCHK,  and  all  READ  statements  are 
made  into  comment  statements.  All  non- int rastatement  errors 
are  printed  ahead  of  and  following  the  symbol  table  for  the 
program  unit.  The  symbol  table  lists  all  symbolic  names 
and  the  type,  dimensionality,  and  relocation  of  each  name. 

In  addition,  all  externals,  statement  labels,  and  COMMON 
blocks  are  listed,  along  with  associated  information.  If  the 
flow  analysis  mode  is  selected,  the  results  of  the  flow 
analysis  are  printed.  For  each  variable  that  is  referenced 
but  not  defined  along  some  path,  the  variable  and  the  state- 
ment labels  of  the  path  are  indicated.  A variable  may  be 
flagged  only  once.  The  number  of  paths  checked  are  also 
i nd  icated . 

Each  time  AUDIT  is  executed,  a global  reference  table  is 
printed.  This  table  lists  all  external  references,  labeled 
COMMON  blocks,  and  program  units  encountered  (and  their 
associated  information)  for  all  the  program  units  examined. 

If  the  roll  call  mode  is  selected,  the  following  items  will  be 
printed  after  the  global  reference  table  for  each  program  unit. 

1.  Compilation  of  the  revised  program  unit  (see 
Sect  ion  3 . 2 . 2 . 1 ) . 

2.  Compilation  of  main  program  ROLCAL. 

3.  Load  map. 

4.  Results  of  the  roll  call  check. 

5.  Whatever  the  program  unit  has  written  on  output 
devices  X , Y , and  Z . 

If  the  variable  precision  mode  is  selected,  the  revised  pro- 
gram file  will  be  compiled.  For  each  bit  configuration 
selected,  the  (printed)  output  of  the  executable  program  is 
printed.  Appendix  A contains  a representative  sample  of  the 
various  kinds  of  printouts. 
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ShJCTlON  4. 


(MYOGRAM  ASShMBLING,  LOADING,  AND  MAINTENANCt) 
RROCEDUKES 


I nput  /'Out  put  Requ  1 1 ement  s ■ The  followLn<j  components  make 
up  the  AUDIT  system: 

1.  Audit  mode  sout  ce  code  softwa/e 

2.  Roll  call  mode  soui ce  code  softwaie 

J.  Piogiam  S ESDI  ST  and  data 

4.  Piogiam  GRAPH  and  data 

5.  Vat  Lable  ptecision  function  subpiogiams. 

Pot  the  put  poses  of  this  document  it  is  assumed  that  the  audit 
and  toll  call  mode  souice  code  softwaie  is  stored  on  tape  as 
two  souice  files,  and  that  the  othei  components  exist  in  the 
fotm  of  caid  decks.  The  toll  call  souice  softwaie  consists  of 
subroutines  CMPARE,  MODID,  and  ROLCHK . The  audit  mode  source 
software  consists  of  all  the  programs  desct  ibed  in  Section 

1.2  (excluding  QICOMP,  QIDPRE,  QiREAL,  ROLCAL,  CMPARE,  MODID, 
and  ROLCHK).  Before  the  AUDIT  system  can  be  executed,  pro- 
grams SESLIST  and  GRAPH  must  create  the  Interface  Definition 
file  and  the  syntax  graph  file,  respectively.  The  user  then 
specifies  these  two  files  as  input  to  the  audit  mode  software 
ana  inputs  the  options  card  (must  be  card  input)  and  the  soft- 
ware to  be  examined  (must  be  card,  tape,  or  aisk  input).  If 
the  vat  iable  precision  mode  is  selected,  the  vai  iable  pre- 
cision function  subprograms  (for  the  bit  conf  igur at  ions 
aesiied)  are  then  input.  The  control  cards  ate  all  that  remain 
to  execute  the  AUDIT  system. 

4.2  Pi  ocedui es . The  AUDIT  system  is  executed  in  the  batch 

moae.  As  stated  in  Section  4.1,  it  is  assumed  that  the  audit 
and  roll  call  mode  souice  software  is  stored  on  tape  as  two 
consecutive  files  and  that  all  other  components  are  in  the 
form  of  card  oecks.  This  need  not  be  the  case,  but  tor  the 
purposes  of  explaining  all  possible  operating  procedures, 
this  construct  is  assumed.  It  is  also  assumed  that  all 
permanent  files  genet ateu  by  the  AUDIT  components  ate  stored 
as  disk  files.  It  will  be  easy  for  the  user  to  adapt  to 
other  physical  mediums  if  he  shall  so  choose. 

The  control  cards  needed  to  execute  all  possible  options 
of  the  AUDIT  system  will  be  listed  and  desct  ibea  for  the 
following  three  processors: 

1)  CDC  bOUU  set  les,  SCOPE  3.4  operating  system 

2)  UN  I VAC  llu8,  EX EC -a  operating  system 

3)  IBM  3bU,  OS-3bU  operating  system. 

Pot  each  possible  option,  only  Column  1 and  Column  b of  the 
options  data  card  are  discussed.  The  flow  analysis  mode  may 
be  selected  for  any  audit  mode,  toll  call  mode,  or  vai  iable 
precision  mode,  and  is  controlled  by  Column  s of  the  options 
card.  The  ANSI  name  check  may  also  be  selected  for  any  mode, 
ana  is  controlled  by  Column  13.  If  the  variable  ptecision 
mode  is  selected  and  the  executable  program  leguiies  tape  or 


ulsk  data,  such  data  must  be  made  availv^nle  to  the  pioytam 
by  ass  i>.j  n t nij  the  appi  opt  Late  input  files.  The  files  must 
be  I ewound  tot  each  bit  con f i>g ui  at  ion  executed. 

It  is  oitticult  to  state  piecise  timing  estimates  of 
the  vat  lous  AUDIT  options.  It  is  best  to  fust  analyze  a 
few  subpiogiams  using  the  vat  ious  options  and  then  use  those 
times  as  a base  fot  tutuie  tuns.  The  only  option  that  may 
De  time  consuming  is  the  flow  analysis  mode,  whet e the  time 
IS  depenaent  on  the  numbei  of  paths.  Fot  subptogtams  that 
have  paths  that  numbet  in  the  thousands,  it  may  be  bettet 
to  use  the  modet ate  flow  analysis.  Only  by  ti  ial  and  eitot 
will  a uset  be  able  to  get  a feeling  fot  the  amount  of  time 
needed  to  execute.  When  tunning  the  vat  iable  ptecision  mode, 
the  uset  should  have  an  estimate  of  the  execution  time  of  the 
piogtam  to  be  analyzed.  Then  fot  all  the  bit  con f ig ut a t ions 
to  be  analyzed,  the  uset  should  allow  enough  time  to  execute 
the  ptogtam  the  desited  numbei  of  times  {in  addition  to  the 
audit  time).  Timing  estimates  wet e computed  fot  some  of  the 
piogiams  listed  in  Appendix  A.  To  pet  fot  m the  audit  mode 
lot  the  main  piogtam  SAMP,  the  ext t aoi d inat y subtoutine 
INOUT,  and  the  BLOCK  DATA  subpiogtam,  it  took  about  5.U  CPU 
seconds  on  the  CDC  64UU  and  the  UNI\/AC  1108  and  2.8  seconds 
on  the  IBM  160.  To  petfotm  the  toll  call  mode  fot  subtoutine 
APNDGA,  It  took  about  20.0  CPU  seconds  fot  the  CDC  6400  and 
the  UNIVAC  1108  and  14.8  seconds  fot  the  IBM  360. 

4.2.1  CDC  6000 . The  conttol  catds  listed  in  this  section 
ate  applicable  to  the  SCOPE  3.4  opeiating  system.  Apptoptiate 
moo  1 f icat  ions  ate  easily  made  fot  diffetent  opeiating  systems. 

4.Z.1.1  Initial  File  Ci eat  ion.  The  following  fout  files 
must  be  cieated  initially: 

1.  Inteiface  Definition  file 

2.  Syntax  gt aph  file 

3.  Absolute  binaty  veision  of  the  audit  mode  soutce 
soft wat  e 

4.  Relocatable  binaty  veision  of  the  toll  call  mode 
sout  ce  sot  t wat  e . 

To  cieate  the  Inteiface  Definition  file,  execute  ptogtam 
SESLIST  ana  catalogue  the  output  •.  1 1 e with  a petmanent  file 
name  of  IDFILE.  To  cieate  the  syntax  gtaph  file,  execute 
ptogtam  GRAPH  and  catalogue  the  output  file  with  a petmanent 
1 lie  name  of  SYNTAXGRAPH.  The  audit  binaty  veision  (PFN  = 
AUDll'BIN)  and  the  toll  call  binaty  veision  ( PFN  = ROLLCALLBIN ; 
ate  cieated  f i om  the  soutce  labeled  tape  ( L=AUD1TS0URCE ) 
using  the  following  conttol  catds: 

1.  Standaid  SCOPE  Job  caid  (lequesting  CM13U0UU,  MTl, 
and  T 3 u U ) 

2.  Standaid  SCOPE  chaige  caid 

5.  VSN(TAPE=SESul=SLOTXX. 
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4 . LABEL  (TAPE  , L = AUDITSOURCE  , R)  ( NORI  NG/SESO 1 /S  I.OTXX  ) 
REQUEST ( AUD, *PF) 

6.  REQUEST! RLCL, *PF) 

7.  COPYBF{ TAPE, AUDIT) 

8.  COPYBF( TAPE , ROLL) 
y.  RETURN (TAPE) 

10.  REWIND(AUDIT,ROLL) 

11.  RFL(7UUU0) 

12  . FTN(  1=AUD1T,  B = AUDBIN  , I.  = 0 ,OPT=2  ) 

13.  FTN( I=HOLL,B=RLCL,L=0,OPT=2) 

1 4 . CATALOG! RLCL, ROLLCALLBIN , I D = XXXX , AC  = XXXXXXXXXX ) 
IS.  RFL(13U0U0) 
lb.  LOAD(AUDBIN) 

17.  NOGO(AUD) 

18.  CATALOG! AUD, AUDI TBIN, I D=XXX , AC=XXXXXXXXXX ) 
ly.  6/7/8/y  End-o£-file 


EXPLANATION  OF  CARDS 

3. -4.  Mount  AUDIT  soui ce  tape.  Note  that  these  caids  may 
be  Installation  dependent. 

b.-6.  Request  permanent  file  devices  foi  files. 

7.-y.  Copy  source  files  from  tape  to  temporary  disk  files 

and  r e 1 ease  tape . 

12.-13.  Compile  audit  and  roll  call  source.  Note  that  if  a 
listing  of  the  source  is  desired,  omit  L=0. 

14.  Catalog  the  roll  call  mode  programs  in  relocatable 

b inar  y form. 

16.  Load  the  relocatable  binary  file. 

Id.  Catalog  the  audit  programs  in  absolute  binary  form. 

4. 2. 1.2  Execute  Audit  Mode  from  Cards.  If  the  software  to  be 

examined  is  on  cards,  the  following  sequence  of  raids  is  used 

to  execute  the  audit  mode. 


1 . 
2 . 

3 . 

4 . 

5 . 

6 . 

7 . 

8 . 
y . 


Standard  SCOPE  Job  card  (CM13UUUU) 
Standard  SCOPE  charge  card 
ATTACH (TAPE 4 , IDFILE, ID=XXXX) 

ATTACH ( TAPEl y , S YNTAXGRAPH , I D=XXXX ) 
ATTACH! AUD, AUDI TBIN, ID=XXXX) 

AUD. 

7/8/y  End-of- r ecor d 

Options  card 

Software  to  be  examined 


lU  . 6/7/8/y  End-of-f i le 
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EXPLANATION  OF  CARDS 


J1.-4.  Attach  input  files. 

).-b.  Attach  and  execute  audit  absolute  binaiy  file, 
a.  Options  caid  is  punched  with  a 1 in  Column  1 and  a 5 

in  Column  d. 

a.  At  least  one  piogiam  unit  is  needed.  Only  one  main 

piogtam  is  peimitted. 

4 ^ Execute  Audit  Mode  fiom  Sequential  Disk  oi  Tape  File. 

A sequential  file  must  contain  at  least  one  piogiam  unit.  If 
theie  is  moi  e than  one  piogiam  unit,  all  piogiam  units  must 
be  consecutively  stoi ed  without  any  embedded  end-of-i ecoi ds 
between  piogiam  units.  Only  one  main  piogiam  is  peimitted. 

If  the  softwaie  to  be  examined  is  on  a sequential  disk  file, 
the  following  sequence  of  caids  is  used  to  execute  the  audit 
mode . 


1 .-b. 

Same  as  1-5  of  Section  4.2 

b . 

ATTACH ( TAPE7  , PFN,  ID  = XXXX) 

7 . 

ADD. 

8 . 

7/8/y  End-of-i ecoi  d 

y . 

Opt  ions  caid 

10  . 

6/7/8/y  End-of-file 

EXPLANATION  OF  CARDS 

6.  PFN  is  the  name  of  the  peimanent  file  on  which  the  soft- 

waie to  be  examined  lesides. 

4.  Options  caid  is  punched  with  a 1 in  Column  1 and  a 7 in 

Column  b. 

If  the  softwaie  to  be  examined  is  on  a sequential  standaid 
SCOPE  labeleo  tape  file,  the  following  two  caids  leplace  Caid  6. 
6a.  VSN(TAPE7=VRN0) 

6b.  LABEL(TAPE7 ,L=  NAME  ,R)  ( VRNO/NORING) 

wheie  VRNO  is  the  visual  leel  numbei  of  the  tape,  and  NAME  is 
the  tape  label  name.  If  the  softwaie  to  be  examined  is  on  a 
sequential  stiangei  tape,  the  following  two  caids  leplace  Caid  6. 
6a.  VSN(TAPE7=VRNO) 

6b.  REQUEST(TAPE7, DEN, TYPE)  (VRNO/NORING) 
wheie  DEN  is  HI,  HY,  oi  HD  (556  seven  tiack,  800  seven  tiack, 
and  800  nine  tiack,  i espect ivel y ) and  TYPE  is  S oi  L (S  foi 
i ecoi  a sizel512  woids  and  L foi  lecoid  size  >512  woids). 

4. 2. 1.4  Execute  Audit  Mode  fiom  Update  Disk  oi  Tape  File. 

The  update  file  must  contain  at  least  one  piogiam  unit.  Only 
one  main  piogiam  is  peimitted  pet  execution.  If  the  softwaie 
to  be  examined  is  stoied  on  an  update  disk  file,  the  following 
sequence  of  caids  is  used  to  execute  the  audit  mode. 


86 


T 


1.-5.  Same  as  1-5  of  Section  4. 2. 1.2. 

6.  ATTACH (OLDPL,  PFN  ,ID=XXXX) 

7.  UPDATE(Q,C=TAPE7 ) 

8.  AUD. 

9.  7/8/9  End-of-tecord 

10.  *C  DECKl,  DECK2,  DECKn 

11.  7/8/9 

12.  Options  card 

13.  6/7/8Z9  End-of-file 

EXPLANATION  OF  CARDS 

6.  PFN  is  the  name  of  the  permanent  file  on  which  the  software 
to  be  examined  resides. 

7.  Call  the  update  utility  to  select  the  decks  from  the  update 
file  that  the  user  wishes  to  examine.  If  the  user  wishes 
to  examine  all  decks  on  the  update  file,  replace  the  Q with 
an  F . 

10.  DECKl,  DECK2,  DECKn  are  the  specific  decks  to  be 

examined.  If  an  F is  on  the  update  card  (Card  7),  omit 
this  card. 

12.  Options  card  is  punched  with  a 1 in  Column  1 and  a 7 in 
Column  5. 

If  the  software  to  be  examined  is  on  an  update  labeled 
tape  file,  the  following  two  cards  replace  Card  6. 

6a.  VSN(TAPE7=VRNO) 

6b.  LABEL(OLDPL,  L=  NAME  , R)  ( VRNO/NORI NG ) 
where  VRNO  is  the  visual  reel  number  of  the  tape  and  NAME  is 
the  tape  label  name.  If  the  software  to  be  examined  is  on  an 
update  stranger  tape  file,  the  following  two  cards  replace 
Card  6. 

6a.  VSN(TAPE7=VRNO) 

6b.  REQUEST(OLDPL, DEN, TYPE)  ( VRNO/NORI NG ) 
where  DEN  is  HI,  HY,  or  HD  (556  seven  track,  800  seven  track, 
and  800  nine  track,  respectively)  and  TYPE  is  S or  L (S  for 
record  size_512  words  and  L for  record  size>512  words). 

4 . 2 . 1 . 5 Execute  Audit  Mode  and  Roll  Call  Mode  from  Cards. 

When  the  roll  call  mode  is  selected,  the  audit  mode  generates 
a revised  roll  call  program  file  for  the  program  unit  being 
examined.  Therefore,  the  roll  call  mode  must  be  executed, 
along  with  the  audit  mode,  once  per  program  unit.  If  the 
software  to  be  examined  is  on  cards,  the  following  sequence 
of  cards  is  used  to  execute  the  audit  mode  and  the  roll  call 
mode  for  a single  program  unit. 

1.  Standard  SCOPE  Job  card  (CM130000) 

2.  Standard  SCOPE  charge  card. 

3.  ATTACH(TAPE4 , IDFILE, ID=XXXX) 

4 . ATTACH(TAPE19,SYNTAXGRAPH,ID=XXXX) 

5.  ATTACH(AUD,AUDITBIN, ID=XXXX) 
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6. 
7 . 
8. 
9. 

10. 
11 . 
12. 

13. 

14. 

15. 

16. 


ATTACH ( RLCL,ROLLCALLBIN, I D=XXXX) 

AUD. 

FTN( I=TAPE8) 

LOAD( RLCL) 

LGO. 

COPYSBF(TAPE  13)1 

COPYSBF(TAPE  14)V  Used  only  for  a value  of 
COPYSBF(TAPE  15)1  Column  1 of  options  card 
7/8/9  End -of- record 
Options  card 
Software  to  be  examined 


2 in 


17.  6/7/8Z9  End-of-file 

EXPLANATION  OF  CARDS 


3.-4. 

5.-6. 

7. 

8. 

9.-10. 

11.-13 


15. 

16. 


Attach  input  files. 

Attach  audit  and  roll  call  binary. 

Execute  audit  binary. 

Compile  the  revised  roll  call  program  file. 

Load  the  roll  call  binary  and  the  revised  roll  call 
program  file  and  execute. 

Display  information  written  on  output  devices  X,  Y, 
and  Z by  the  program  unit  being  examined.  These 
cards  are  only  used  when  Column  1 of  the  options  card 
contains  a 2. 

Options  card  is  punched  with  a 2 or  3 in  Column  1 
and  a 5 in  Column  5. 

Software  must  be  a root  program  unit  of  a module. 


The  following  sequence  of  cards  (which  includes  cards 
identified  in  the  previous  sequence)  is  used  to  execute  the 
audit  mode  and  the  roll  call  mode  from  cards  for  more  than 
one  program  unit. 


Cards  1-6 
Cards  7-13 
REWIND, LGO^ 
Cards  7-13 ) 
REWIND, 

Cards 


( for 
(for 


program 

program 


unit 

unit 


1) 

2) 


) , LGO 
7-13  C 

] 


(for  program  unit  3) 


(for  additional  program  units) 


7/8/9  End-of-r ecord 
Options  card 
Program  unit  1 
7/8/9 

Options  card 
Program  unit  2 
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T 


'4 


7/b/9 
Opt  Lons 
Program 
7/8/9 


6/7/b/9 


card 
unit  3 


] 

End-of - 


(for  additional  program  units) 
file 


4. 2. 1.6  Execute  Audit  Mode  and  Roll  Call  Mode  from  Sequential 
File.  If  there  is  more  than  one  program  unit  on  a sequential 
tape  or  disk  file,  the  audit  mode  can  be  executed  only  if  there 
are  end-of-record  marks  between  program  units.  Since  this  way 
of  storing  source  code  is  not  typical,  a description  of  the 
control  cards  needed  to  execute  the  audit  and  roll  call  mode 
is  not  provided.  The  user  who  wants  to  do  it  this  way  may 
construct  the  control  cards  by  following  the  control  card  logic 
given  for  executing  from  cards  or  an  update  file. 


4. 2. 1.7  Execute  Audit  Mode  and  Roll  Call  Mode  from  Update 
Disk  or  Tape  File.  When  the  roll  call  mode  is  selected,  the 
audit  mode  generates  a revised  roll  call  program  file  for  the 
program  unit  being  examined.  Therefore,  the  roll  call  mode 
must  be  executed,  along  with  the  audit  mode,  once  per  program 
unit.  If  the  software  to  be  examined  is  on  an  update  disk 
file,  the  following  sequence  of  cards  is  used  to  execute  the 
audit  mode  and  the  roll  call  mode  for  a single  program  unit. 


1.  Standard  SCOPE  Job  card  (CM130U00  and  MTl ) 

2.  Standard  SCOPE  charge  card 

3.  ATTACH(TAPE4 , IDFILE, ID=XXXX) 

4 . ATTACH(TAPE19,SYNTAXGRAPH, ID=XXXX) 

5.  ATTACH(AUD,AUDITBIN, ID=XXXX) 

6.  ATTACH( RLCL,ROLLCALLBIN, ID=XXXX) 


7.  ATTACH (OLDPL,  PFN  ,ID 

8.  UPDATE(Q,C=TAPE7) 

9.  AUD. 

10.  FTN(I=TAPE8) 

11.  LOAD(RLCL) 

12.  LGO. 

13.  COPYSBF(TAPE13)  / 

14.  C0PYSBF(TAPE14)  > 

15.  COPYSBF(TAPEIS)  \ 

16.  7/8/9  End-of-record 

17.  *C  DECK 

18.  7/8/9 

19 . Opt  ions  card 

20.  6/7/B/9  End-of-file 


XXXX) 


Used  only  for  a value  of  2 in 
Column  1 of  options  card. 
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EXPLANATION  OF  CARDS 


J .-4  . 
5.-6. 

7 . 

d . 

y . 

lu. 

11  .-12  . 
13.-15. 


17  . 
ly . 


The  following  sequence  of  cards  (which  includes  caids 
identified  in  the  previous  sequence)  is  used  to  execute  the 
audit  mode  and  the  loll  call  mode  fiom  an  update  disk  file  for 
mote  than  one  piogiam  unit. 


Cards 

1-7 

Cards 

8-15 

(for 

pr  og  r am 

unit 

1) 

REWIND 

Cards 

,LG0.7 

8-15  3 

( for 

pr  og  r am 

unit 

2) 

REWIND 

Cards 

, LGO  .S 

8-15  C 

(for 

pr  og  r am 

unit 

3) 

(for  additional  piogiam  units) 

7/y/y  End-of-r ecoj d 

*C  DECKl 

7/8/y 

Options  ca»d 
7/b/y 
*C  DECK2 
7/b/y 

Options  card 
7/b/y 
*C  DECKS 
7/8/y 

Options  caid 

. ^ (for  additional  piogtam  units) 

6/7/b/y  End-of-file 


Attach  input  files. 

Attach  audit  and  loll  call  binaiy. 

PFN  is  the  name  of  the  petmanent  file  on  which  the 
softwaie  to  be  examined  tesides. 

Call  the  update  utility  to  select  the  deck  fiom  the 
update  file  which  the  usei  wishes  to  examine. 

Execute  audit  binary. 

Compile  the  revised  roll  call  program  file. 

Load  the  roll  call  binary  and  the  revised  roll  call 
program  file  and  execute. 

Display  information  that  has  been  written  on  output 
devices  X,  Y,  and  Z by  the  program  unit  being  analyzed, 
These  control  cards  are  only  used  when  Column  1 of  the 
options  card  contains  a 2. 

DECK  is  the  specific  program  unit  to  be  examined.  It 
must  be  the  root  program  unit  of  a module. 

Options  card  is  punched  with  a 2 or  3 in  Column  1 and 
a 7 in  Column  5. 


■4 


If  the  software  to  be  examined  is  on  an  update  labeled 
tape  file,  the  following  two  cards  replace  card  7. 

7a.  VSN(TAPE7=VRN0) 

7b.  LABEL(OLDPL,  L=  NAME  ,R)  ( VRNO/NORING ) 
where  VRNO  is  the  visual  reel  number  of  the  tape  and  NAME  is 
the  tape  label  name.  If  the  software  to  be  examined  is  on  an 
update  stranger  tape  file,  the  following  two  cards  replace 
card  7. 

7a.  VSN(TAPE7=VRN0) 

7b.  REQUEST(OLDPL, DEN, TYPE)  (VRNO/NORING) 
where  DEN  is  HI,  HY,  or  HD  (556  seven  track,  800  seven  track, 
and  800  nine  track,  respectively)  and  TYPE  is  S or  L (S  for 
record  size  £512  words  and  L for  record  size  >512  words). 

4. 2. 1.8  Execute  Audit  Mode  and  Variable  Pr ec i sion  Mode  from 
Cards . The  variable  precision  mode  processes  an  entire 
executable  program.  If  the  executable  program  to  be  examined 
is  on  cards,  the  following  sequence  of  cards  is  used  to  execute 
the  audit  mode  and  the  variable  precision  mode  for  a single  bit 
conf iguration . 

1.-6.  Same  as  1-6  from  Section  4. 2. 1.2 

7.  FTN(I=TAPE8) 

8.  FTN(B=VPLIB) 

9.  LOAD(VPLIB) 

10.  LGO. 

1] . 7/8/9  End-of-record 

12.  Options  card 

13.  Executable  program  (without  data  cards) 


14.  7/8/9 

15.  Variable  precision  function  subprograms 


16.  7/8/9 

17.  Data  cards  for  executable  program 


18.  6/7/8Z9  End-of-file 
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EXPLANATION  OF  CARDS 


7.  Compile  the  levised  vaiLable  piecision  piogiam  file 

which  is  generated  by  the  audit  mode.  This  file 
contains  references  to  the  var  iable  precision 
function  subprograms. 

B.  Compile  the  variable  precision  function  subprograms. 

9.-1U.  Load  the  variable  precision  function  subprograms  and 
tne  revised  variable  precision  program  file  and  then 
execute . 

12.  Options  card  is  punched  with  a 1 in  Column  1 and  a 
5 in  Column  5. 

13.  Executable  program  (without  data  cards)  must  contain 
a main  pr  og r am . 

15.  Three  variable  precision  function  subprograms  (QIREAL, 

QlDPRE,  and  QICOMP)  for  the  particular  bit  configu- 
r at  ion  desir  ed . 

17.  Data  cards  for  executable  program.  If  additional  data 

is  on  tape  or  disk,  the  user  must  make  such  data 
available  to  the  executable  program. 

The  following  sequence  of  cards  (which  includes  cards 
identified  in  the  previous  sequence)  is  used  to  execute  the 
auait  mode  and  the  variable  precision  mode  from  cards  for  more 
than  one  bit  configuration. 


Cards  1-7 
Cards  8-10 

REWIND, VPLIB. 
Cards  8-10 
REWIND, VPLIB. 
Cards  8-10 


(for  variable  precision 
programs  1) 

(for  variable  precision 
pr  og  r ams  2 ) 

(for  variable  precision 
pr  ogr  ams  3 ) 


function  sub- 
function sub- 
function sub- 


. C (additional  variable  precision  function 

. 3 subpr  ogr  ams ) 

7/8/9  End-of-r ecor d 
Options  card 

Executable  program  (without  data  cards) 


7/8/9 

Variable  precision  function  subprograms  1 
7/8/9 

Data  cards  for  executable  program 
7/8/9 

Variable  precision  function  subprograms  2 
7/8/9 

Data  cards  for  executable  program 
7/8/9 

Variable  precision  function  subprograms  3 
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9 


7/8/y 

Data  caids  foi  executable  ptogiatn 

y (additional  vai iable  piecision  function 
. J subpi ogi ams ) 

6/7/8/y  End-of-file 

4.2.1.y  Execute  Audit  Mode  and  Vat  iable  Piecision  Mode  £ i om 
Sequential  Disk  oi  Tape  File.  The  vai iable  piecision  mode 
pi ocesses  an  entiie  executable  piogiam.  If  the  executable 
piogiam  to  be  examined  is  on  a sequential  disk  file  and  data 
is  on  cards,  the  following  sequence  of  caids  is  used  to  execute 
the  audit  mode  and  the  vai iable  piecision  mode  foi  a single 
bit  conf igui  at  ion . 


I. -5.  Same  as  1-5  fiom  Section  4. 2. 1.8 

b.  ATTACH ( TAPE7 , PEN  ,ID=XXXX) 

7.  ADD. 

8.  FTN(I=TAPE8) 

y.  FTN(B=VPLIB) 

lU.  LOAD(VPLIB) 

II.  LGO. 

12.  7/8/y  End-of-i  ecoi d 

13.  Options  card 

14.  7/8/y 

15.  Vai iable  piecision  function  subpiogiams 


lb.  7/8/y 

17.  Data  caids  foi  executable  piogiam 


18.  6/7/8/9  End-of-file 

EXPLANATION  OF  CARDS 


6. 

7. 

8. 


y. 

lO.-ll  . 
13. 


PFN  is  the  name  of  the  permanent  file  on  which  the 
executable  program  resides. 

Execute  the  audit  binary. 

Compile  the  revised  variable  precision  program  file 
which  is  generated  by  the  audit  mode.  This  file 
contains  references  to  the  variable  piecision  function 
subpi ogr ams . 

Compile  the  variable  precision  function  subprograms. 
Load  the  variable  precision  function  subprograms  and 
the  revised  variable  piecision  program  file  and  then 
execute . 

Options  card  is  punched  with  a 1 in  Column  1 and  a 
7 in  Column  5. 
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I ■j . Thiee  vai  iable  piecLsion  function  subptoqtams  (QlREAL, 

QIDPRE,  and  QICOMP)  foi  the  paiticulai  bit  conf  Lcju- 
1 at  Lon  des  L I ed  . 

The  tollowLnq  sequence  of  caids  (which  includes  caids 
identitieo  in  the  pievious  sequence)  is  used  to  execute  the 
audit  mode  and  the  vai  iable  piecision  mode  f i om  a sequential 
disk  tile  (executable  piogiam  on  file  and  data  on  caids)  foi 
mote  than  one  bit  conf  igui at  ion . 


Cards  1-d 
Caids  9-11 

REWIND, VPLIB. 
Caids  0-11 
REWIND,  VPLIB 
Caids  9-11 


(foi  vai  iable  piecision  function  sub- 
pt  og 1 ams  1 ) 

(foi  variable  piecision  function  sub- 
pi  og 1 ams  2 ) 

(foi  vai iable  piecision  function  sub- 
pt  og 1 ams  3 ) 


> (foi  additional  variable  piecision 
. ) function  subpiogiams) 

7/8/9  End-of -1 ecoi d 
Opt  ions  cai d 
7/8/9 

Variable  piecision  function  subpiogiams  1 
7/8/9 


Data  caids  for  executable  ptogtam 
7/8/9 

Variable  piecision  function  subpiogiams  2 
7/8/9 

Data  caids  for  executable  piogiam 
7/8/9 

Variable  piecision  function  subprograms  3 
7/8/9 

Data  caids  foi  executable  piogiam 


] 


(for  additional  variable 
function  subpiogiams) 
b/7/8/9  End-of-file 


piecision 


If  the  executable  piogiam  is  on  a labeled  ot  a stiangei 
sequential  tape  file,  substituce  two  caids  foi  Caid  6,  as 
described  in  Section  4. 2. 1.3. 


4.2.1.1U  Execute  Audit  Mode  and  Vai  iable  Piecision  Mode  fiom 
Update  Disk  oi  Tape  File.  The  variable  piecision  mode  processes 
an  entire  executable  program.  If  the  executable  program  is  on 
an  update  disk  file  and  data  is  on  cards,  the  following  sequence 
of  cards  is  used  to  execute  the  audit  mode  and  the  var  iable 
precision  mode  for  a single  bit  configuration. 

1.-5.  Same  as  1-5  from  Section  4. 2. 1.8. 

6.  ATTACH(OLDPL,  PEN  ,ID=XXXX) 
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UPDATE (Q,C=TAPE7 ) 

AUD. 

FTN( I=TAPE«) 

ETN( B=VPLIB) 

LOAD( VPLIB) 

LGO. 

7/8/9  End-of - 1 ecoi  d 

*C  DECKi,DECK2, ,DECKn 

7/8/9 

Opt  ions  Cai d 
7/8/9 

Vai iable  piecision  function  subpiogtams 


7^/9 

Data  catds  fo(  executable  ptogiam 


6/7/8/9  End-of-file 

EXPLANATION  OF  CARDS 


PFN  is  the  name  of  the  petmanent  file  on  which  the 
executable  piogiam  lesides. 

Call  the  update  utility  to  select  the  decks  fiom  the 
update  file  which  make  up  the  executable  piogiam. 

If  the  executable  piogiam  consists  of  all  decks  on 
the  update  file,  leplace  the  Q with  an  F. 

Execute  the  audit  binaiy. 

Compile  the  levised  vai  iable  piecision  piogiam  file 
which  is  genei ated  by  the  audit  mode.  This  file 
contains  lefeiences  to  the  vai  iable  piecision 
function  subpiogiams. 

Compile  the  vai  iable  piecision  function  subpiogiams. 
Load  the  vai iable  piecision  function  subpiogiams 
and  the  levised  vai  iable  piecision  piogiam  file  and 
execute . 

DECKl,DECK2, ,DECKn  aie  the  specific  decks  that 

make  up  the  executable  piogiam.  One  and  only  one 
deck  must  be  a main  piogiam.  If  an  F is  on  the  update 
caid  (caid  7),  omit  this  caid. 

Options  caid  is  punched  with  a 1 in  Column  1 and  a 7 
in  Column  5. 

Thiee  variable  piecision  function  subpiogiams  (QlREAL, 
QIDPRE,  and  QlCOMP)  foi  the  paiticulai  bit  configu- 
1 at  ion  des  i 1 ed  . 

Data  caids  foi  the  executable  piogiam.  If  additional 
data  is  on  disk  oi  tape,  the  usei  must  make  such  data 
available  to  the  executable  piogiam. 
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The  following  sequence  of  cards  (which  includes  cards 
identified  in  the  previous  sequence)  is  used  to  execute  the 
audit  mode  and  the  variable  precision  mode  from  an  update 
disk  file  (executable  program  on  file  and  data  on  cards)  for 
more  than  one  bit  conf  igur at  ion . 


Cards  1-y 
Cards  10-12 

REWIND, VPLIB  ? 
Cards  10-12  J 
REWIND, VPLIB  5 
Cards  10-12  5 


(for  variable  precision  function  sub- 
programs 1) 

(for  variable  precision  function  sub- 
programs 2) 

(for  variable  precision  function  sub- 
prog r ams  3 ) 


> (for  additional  variable  precision 
. 3 function  subprograms) 

7/8/y  End-of-record 
Cards  14-16 
7/8/y 


Variable  precision  function  subprograms  1 
7/8/y 

Data  cards  for  executable  program 
7/8/y 

Variable  precision  function  subprograms  2 
7/8/y 

Data  cards  for  executable  program 
7/8/y 


Variable  precision  function  subprograms  3 
7/8/9 

Data  cards  for  executable  program 


5 


(for  additional  variable 
function  subprograms) 
6/7/8/y  End-of-file 


prec  is  ion 


If  the  executable  program  is  on  a labeled  or  a stranger 
update  tape  file,  substitute  two  cards  for  Card  6,  as  described 
in  Sect  ion  4 . 2 . 1 . 4 . 


4.2.2  UNIVAC  1108.  The  control  cards  listed  in  this  section 
are  applicable  to  the  UNIVAC  1100  series  with  EXEC-8  operating- 
system  . 


4. 2. 2.1  Initial  File  Creation.  The  following  four  files  must 
be  created  initially: 

1.  Interface  Definition  file 

2.  Syntax  graph  file 

3.  Absolute  binary  version  of  the  audit  mode  source  soft- 
ware. 

4.  Relocatable  binary  version  of  the  roll  call  mode 
source  software. 
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1 


To  create  the  Interface  Definition  file,  execute  program 
SDSLIST  and  catalogue  the  output  file  with  a file  name  of 
IDFILE.  To  create  the  syntax  graph  file,  execute  program 
GRAPH  and  catalogue  the  output  file  with  a file  name  of 
SYNTAXGRAPH.  The  audit  binary  version  (with  a file  name  of 
AUDITBIN)  and  the  roll  call  binary  version  (with  a file  name 
of  ROLLCALLBIN)  are  created  from  the  source  unlabeled  tape 
(with  a file  name  of  TAPE)  using  the  following  control  cards: 

1.  Standard  EXEC-8  Job  card 

2,  ■3ASG,TJ  TAPE.  ,8C, AUDIT 

i.  (JASG,UP  AUDITBIN. 

4.  iaASG,T  COMPILE. 

5.  yASG,T  AUDITPL. 

6.  @ASG,T  RLCL. 

7.  tMSG,UP  ROLLCALLBIN. 

8.  ^ASG,T  AUDIT. 

9.  iaCOPY,G  TAPE.  , COMPILE. 

10.  0COPY,G  TAPE. , AUDITPL. 

11.  (dCOPY,G  TAPE., RLCL. 

12.  0ADD  COMPILE. 

13.  iaMAP,SIX  , AUDITBIN  .AUD 

14.  IN  AUDIT. 

15.  ^FOR  RLCL. ROLCHK , ROLLCALLBIN . ROLCHK 

16.  @FOR  RLCL. CMPARE , ROLLCALLBIN .CMPARE 

17.  laFOR  RLCL. MODID, ROLLCALLBIN. MODID 

18.  0FIN 


EXPLANATION  OF  CARDS 


2. 

3. 

4 . 

5. 

6. 

7. 

8 . 

9. 

10  . 

11. 

12. 

13.-14. 

15.-17. 


Mount  AUDIT  source  tape. 

Assign  a catalogued  file  for  the  audit  mode  absolute 
binary . 

Assign  a temporary  file  containing  0FOR  cards  to 
compile  the  AUDIT  source. 

Assign  a temporary  file  for  the  audit  mode  source. 
Assign  a temporary  file  for  the  roll  call  mode  source 
Assign  a catalogued  file  for  the  roll  call  binary. 
Assign  a temporary  file  for  the  audit  binary. 

Copy  the  @FOR  cards  from  tape. 

Copy  the  audit  mode  source  from  tape. 

Copy  the  roll  call  source  from  tape. 

Compile  the  audit  source. 

Call  the  MAP  processor  to  create  an  absolute  binary 
audit  i;,ode  file  with  a name  of  AUDITBIN. 

Compile  the  roll  call  mode  source  and  create  a 
binary  roll  call  mode  file  with  a name  of  ROLLCALLBIN 


4. 2. 2. 2 Execute  Audit  Mode  from  Cards.  If  the  software  to  be 
examined  is  on  cards,  the  following  sequence  of  cards  is  used 
to  execute  the  audit  mode. 
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1 . 

Standard  EXEC-8  Job  card. 

2 . 

0ASG,A  IDFILE. 

3. 

(dASG,A  SYNTAXGRAPH. 

4 . 

gASG.A  AUDITBIN. 

5. 

@USE  4 . , IDFILE. 

6. 

(3USE  19  .,  SYNTAXGRAPH  . 

7. 

(dXQT  AUDITS  I N.AUD 

8 . 

Options  card 

9. 

Software  to  be  examined 

10  . 

0 F I N 

EXPLANATION  OF  CARDS 

2.-3. 

Assign  input  files. 

4. 

Assign  audit  binary. 

5.-6. 

Assign  logical  units  to  input  files. 

7 . 

Execute  the  audit  binary. 

8 . 

Options  card  is  punched  with  a 1 in  Column  1 and  a 

5 in  Column  5. 

9. 

At  least  one  program  unit  is  needed.  Only  one 
program  is  permitted. 

main 

4.2.2. 3 

Execute  Audit  Mode  from  Disk  or  Tape  File.  The 

file 

to  be  examined  must  contain  at  least  one  program  unit. 

Only 

one  main 

program  is  permitted.  If  the  software  to  be  examined 

is  on  a 

disk  or  a tape  SDF  formatted  file  (source),  the 

following  sequence  of  cards  is  used  to  execute  the  audit 

mode . 

1 . 

Standard  EXEC-8  Job  card. 

2. 

^ASG,A  IDFILE. 

3 . 

@ASG,A  SYNTAXGRAPH. 

4. 

^ASG,A  AUDITBIN. 

5. 

Assign  disk  or  tape  with  a file  name  of  AUDFILE 

6. 

@USE  4 . , IDFILE. 

7. 

^USE  19. , SYNTAXGRAPH. 

8. 

0USE  7 . , AUDFILE. 

9. 

@XQT  AUDITBIN. AUD 

10  . 

Options  card 

11 . 

^FIN 

EXPLANATION  OF  CARDS 

5., 8.  AUDFILE  is  the  file  name  on  which  the  software  to 
be  examined  resides. 

10.  Options  card  is  punched  with  a 1 in  Column  1 and  a 

7 in  Column  5. 

(See  Section  4. 2. 2. 2 for  an  explanation  of  the  other  cards.) 
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If  the  software  to  be  examined  is  on  a disk  or  tape 
program  file  (elements),  the  following  sequence  of  cards 
(which  includes  cards  identified  in  the  previous  sequence) 
is  used  to  execute  the  audit  mode. 

Cards  1-5 
iaASG,T  7. 

Cards  6-7 
^DATA,I  7. 
yADD,D  AUDFILE.ELTl 
idADD,D  AUDFILE.ELT2 


^END 

Cards  9-11 

EXPLANATION  OF  CARDS 

An  @ADD,D  card  is  needed  for  each  element  to  be  examined. 
ELTl , ELT2,  etc.,  are  the  element  names. 

4. 2. 2. 4 Execute  Audit  Mode  and  Roll  Call  Mode  from  Cards. 

When  the  roll  call  mode  is  selected,  the  audit  mode  generates 
a revised  roll  call  program  file  for  the  program  unit  being 
examined.  Therefore,  the  roll  call  mode  must  be  executed, 
along  with  the  audit  mode,  once  per  program  unit.  If  the  soft- 
ware to  be  examined  is  on  cards,  the  following  sequence  of 
cards  is  used  to  execute  the  audit  mode  and  the  roll  call  mode 
for  a single  program,  unit. 

1.  Standard  EXEC-8  Job  card. 

2.  ^ASG,A  IDFILE. 

3.  0ASG,A  SYNTAXGRAPH. 

4.  ^ASG,A  AUDITBIN. 

5.  ^ASG,A  ROLLCALLBIN. 

6.  0USE  4 . , IDFILE. 

7.  ^USE  19. , SYNTAXGRAPH. 

8.  ^XQT  AUDITBIN. AUD 

9 . Opt  ions  Card 

10.  Software  to  be  examined 


11.  0END 

12.  (dADD  8. 

13.  ^MAP,IX  ROLL 

14.  IN  TPF$. 

15.  IN  ROLLCALLBIN. 

16.  0XQT  ROLL 
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17. 

0DATA,L 

13. 

18. 

id  END 

19. 

0DATA,  L 

14  . 

20  . 

3END 

21  . 

(dDATA,L 

15. 

22  . 

Id  END 

23. 

0FIN 

Used  only  for  a value  of  2 in  Column  1 
of  options  card. 


EXPLANATION  OF  CARDS 


2.-3.  Assign  input  files. 

4.-5.  Assign  audit  and  roll  call  binary. 

6.-7.  Assign  logical  units  to  input  files. 

8.  Execute  the  audit  binary. 

9.  Options  card  is  punched  with  a 2 or  3 in  Column  1 
and  a 5 in  Column  5. 

10.  Software  must  be  a root  program  unit  of  a module. 

12.  Compile  the  revised  roll  call  program  file. 

13. -15.  Call  the  MAP  processor  to  create  an  absolute  binary 

roll  call  mode  file  composed  of  the  file  in  13.  and 
the  binary  roll  call  software. 

16.  Execute  the  absolute  binary  roll  call  mode  file. 

17. -22.  Display  information  written  on  output  devices  X,  Y, 

and  Z by  the  program  unit  being  examined.  These 
cards  are  only  used  when  Column  1 of  the  options  card 
contains  a 2. 


The  following  sequence  of  cards  (which  includes  cards 
identified  in  the  previous  sequence)  is  used  to  execute  the 
audit  mode  and  the  roll  call  mode  from  cards  for  more  than 
one  program  unit. 


Cards  1-7 
Cards  8-9 
Program  unit 
Cards  11-22 
Cards  8-9 
Program  unit 
Cards  11-22 


^FIN 


1 

■}' 

] 


lj(  for 
for 
{ for 


program  unit  1) 
program  unit  2) 
additional  program  units) 


4. 2. 2. 5 Execute  Audit  Mode  and  Roll  Call  Mode  from  Disk  or 
Tape  File.  When  the  roll  call  mode  is  selected,  the  audit 
mode  generates  a revised  roll  call  program  file  for  the 
program  unit  being  examined.  Therefore,  the  roll  call  mode 
must  be  executed,  along  with  the  audit  mode,  once  per  program 
unit.  If  the  software  to  be  examined  is  on  a disk  or  tape 
program  file  (elements),  the  following  sequence  of  cards  is 
used  to  execute  the  audit  mode  and  the  roll  call  mode  for  a 
single  program  unit. 
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1.-5. 

6 . 

7. 

b.-9. 
lU  . 

11  . 

12. 

13.-14  . 


15.-27  . 


Same  as  1-5  of  Section  4. 2. 2. 4 

Assign  disk  or  tape  with  a file  name  of  KOLLK I hK . 
0ASG,T  7. 

Same  as  6-7  of  Section  4. 2. 2. 4 
$1DATA,I  7. 

0ADD,D  ROLLFILE.ELTNAME 
@END 

Same  as  8-9  of  Section  4. 2. 2. 4 (Options  card  has 
a 7 in  Column  5) 

Same  as  11-23  of  Section  4. 2. 2. 4. 


EXPLANATION  OF  CARDS 

6., 11.  ROLLFILE  is  the  file  name  on  which  the  software  to  be 
examined  resides.  ELTNAME  is  the  element  name  of  the 
element . 


The  previous  sequence  of  cards  is  used  if  only  one  program 
unit  is  to  be  examined.  The  following  sequence  of  cards  (which 
includes  cards  identified  in  the  previous  sequence)  is  used  to 
execute  the  audit  mode  and  the  roll  call  mode  from  a disk  or 
tape  program  file  (elements)  for  more  than  one  program  unit. 


Cards  1-9 
Cards  10-12? 
Cards  13-26> 
Cards  10-12? 
Cards  13-26) 

: ( 

0FIN 


(Card  11  with  the  first  element  name) 
(Card  11  with  the  second  element  name) 


(for  additional  program  units) 


4. 2. 2. 6 Execute  Audit  Mode  and  Variable  Precision  Mode  from 
Cards . The  variable  precision  mode  processes  an  entire 
executable  program.  If  the  executable  program  to  be  examined 
is  on  cards,  the  following  sequence  of  cards  is  used  to  exe- 
cute the  audit  mode  and  the  variable  precision  mode  for  a 
single  bit  configuration. 

1.  Standard  EXEC-8  Job  card. 

2.  (§asg,a  IDFILE. 

3.  0ASG,A  SYNTAXGRAPH. 

4.  @ASG,A  AUDITBIN. 

5.  @USE  4. , IDFILE. 

6.  0USE  19 ., SYNTAXGRAPH . 

7.  ^XQT  AUDITBIN. AUD 

8.  Options  card 

9.  Executable  program  (without  data  cards) 
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10  . 

CdFOH,IS  QIREAL 

1 1 . 

Function  subprogram  QIREAL 

12  . 

:dFOR,IS  QICOMP 

11. 

Function  subprogram  QICOMP 

14  . 

CJFOR,IS  QlDPRE 

15. 

Function  subprogram  QlDPRE 

16  . 

laADD  8. 

17. 

MMAP,IX  VARPRC 

18. 

IN  TPF$. 

19. 

(aXQT  VARPRC 

20. 

Data  cards  for  executable  program 

21 . 

3 F I N 

EXPLANATION  OF  CARDS 

2.- 

3 . 

Assign  input  files. 

4 . 

Assign  audit  binary. 

5.- 

6. 

Assign  I/O  devices  to  input  files. 

7 . 

Execute  the  audit  binary. 

8 . 

Options  card  is  punched  with  a 1 in  Column  1 and  a 
5 in  Column  5. 

9. 

Executable  program  (without  data  cards)  must 
contain  a main  program. 

10. 

-15. 

Compile  variable  precision  function  subprograms 
QIREAL,  QICOMP,  and  QlDPRE.  These  subprograms  must 
all  be  for  the  same  bit  configuration. 

16. 

Compile  the  revised  variable  precision  program  file 
which  contains  references  to  the  variable  precision 
function  subprograms. 

17. 

-18. 

Call  the  MAP  processor  to  create  the  absolute 
binary  variable  precision  file. 

19. 

Execute  the  variable  precision  mode. 

20  . 

Data  cards  for  executable  program.  If  additional 
data  is  on  tape  or  disk,  the  user  must  make  this 
data  available  to  the  executable  program. 

The 

following  sequence  of  cards  (which  includes  cards 

identified  in  the  previous  sequence)  is  used  to  execute  the 
audit  mode  and  the  variable  precision  mode  from  cards  for 
more  than  one  bit  configuration. 
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■4 


Cards  1-8 

executable  program  (without  data  cards) 
10-15  (for  bit  configuration  if 
Cards  16-20  - 

10-15  (for  bit  configuration  2) 

Cards  16-20  — 

. (for  additional  bit  configurations) 

^FIN 


ION  OF  CARDS 

Each  group  of  variable  precision  function  subprograms 
must  be  for  a different  bit  configuration. 


4 ^^^7  Execute  Audit  Mode  and  Variable  Precision  Mode  from 
Disk  or  Tape  File.  The  variable  precision  mode  processes  an 
entire  executaole  program.  If  the  executable  program  is  on  a 
disk  or  tape  SDF  formatted  file  (source)  and  the  data  is  on 
cards,  the  following  sequence  of  cards  is  used  to  execute  the 
audit  mode  and  the  variable  precision  mode  for  a single  bit 
conf igur at  ion . 

I.-IO.  Same  as  1-10  of  Section  4. 2. 2. 3.  (Cards  5 and 
8 have  a file  name  of  VPFILE.) 

11.-22.  Same  as  10-21  of  Section  4. 2. 2. 6 

EXPLANATION  OF  CARDS 

5. ,8.  VPFILE  is  the  name  of  the  file  on  which  the  executable 
program  resides. 

The  following  sequence  of  cards  (which  includes  cards 
identified  in  the  previous  sequence)  is  used  to  execute  the 
audit  mode  and  the  variable  precision  mode  from  tape  or  disk 
for  more  than  one  bit  configuration. 


Cards  1-10 

11-16  (for  bit  configuration  iTl 
Cards  17-21  J 

11-16  (for  bit  configuration  2) 
Cards  17-21 


] 


. (for  additional  bit  configurations) 
0FIN 


E LAN ATI_ON  OF  CARDS 

Each  group  of  variable  precision  function  subprograms 
must  be  for  a different  bit  configuration. 
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If  the  executable  program  to  be  examined  is  on  a disk  or 
tape  program  file  (elements),  the  following  sequence  of  cards 
is  used  to  execute  the  audit  mode  and  the  variable  precision 
mode  for  a single  bit  configuration. 

1.-4.  Same  as  1-4  of  Section  4.2.2. 3 

5.  Assign  disk  or  tape  with  a file  name  of 

VPFILE. 

6.  tdASG,T  7. 

7. -8.  Same  as  6-7  of  Section  4.2.2. 3 

9.  (a DATA,  I 7. 

10.  ^ADD,D  VPFILE. ELTl 

@ADD,D  VPFILE. ELT2 


11.  0END 

12. -13.  Same  as  9-10  of  Section  4.2.2. 3 
14.-25.  Same  as  10-21  of  Section  4. 2.2.6 

EXPLANATION  OF  CARDS 

An  ^ADD,D  card  is  needed  for  each  element  that  makes  up 
the  executable  program.  ELT1,ELT2,  etc.,  are  the  element 
names.  VPFILE  is  the  name  of  the  file  on  which  the  elements 
res ide . 

The  following  sequence  of  cards  (which  includes  cards 
identified  in  the  previous  sequence)  is  used  to  execute  the 
audit  mode  and  the  variable  precision  mode  from  tape  or  disk 
for  more  than  one  bit  configuration. 


1-13  _ 

14-19  (for  bit  configuration  1) 

Cards  20-24  - 

14-19  (for  bit  configuration  2j 

Cards  20-24 

. (for  additional  bit  configurations) 

@FIN 


EXPLANATION  OF  CARDS 


Each  group  of  variable  precision  function  subprograms 
must  be  for  a different  bit  configuration. 

4.2.3 IBM  360.  The  control  cards  listed  in  this  section  are 

applicable  to  the  OS/360  operating  system  for  the  IBM  360. 
Changes  should  be  made  as  appropriate  for  other  operating  sys- 
tems . 
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4 . 2 . 3 ■ 1 Initial  Data  Set  Creation.  The  following  four 
permanent  data  sets  must  be  created  initially: 

1.  Interface  Definition  file 

2.  Syntax  graph  file 

3.  Binary  version  of  the  audit  mode  source  software 

4.  Binary  version  of  the  roll  call  mode  source  software 

To  create  the  Interface  Definition  file,  execute  program 

SKSLIST  and  catalogue  the  output  file  with  a permanent  data 
set  name  of  IDFILE.  To  create  the  syntax  graph  file,  execute 
program  GRAPH  and  catalogue  the  output  file  with  a permanent 
data  set  name  of  SYNTXGRF.  The  audit  binary  version  (with  a 
permanent  data  set  name  of  AUDITBIN)  and  the  roll  call  binary 
version  (with  a permanent  data  set  name  of  RLCLBIN)  are  created 
from  a labeled  tape  using  the  following  control  cards. 

1.  Standard  IBM  Job  card 

2.  //  EXEC  PGM=CSDS,PARM=' LRECL=3120' 

3.  //SYSPRINT  DD  SYSOUT=A 

4.  //INPUT  DD  DSN=NSR. SOURCE, AMK. TAPE, VOL=SER=XXXX, 
UNIT=TAPE9 , 

5.  //  LABEL=( 1 ,SL) ,DCB=( RECFM=U , BLKSIZE=3120 ) ,DISP= 
(OLD, KEEP) 

6.  //OUTPUT  DD  DSN  = i.AUDITBIN,DISP=(NEW,PASS)  ,UNIT  = 
TEMP, 

7.  J/  DCB=( RECFM=FB,LRECL=80,BLKSIZE=3120) ,SPACE= 

( 3120  , (200,5)  ) 

8.  //  EXEC  PGM=CSDS , PARM= ’ LRECL=4000 ’ 

9.  //SYSPRINT  DD  SYSOUT=A 

10.  //INPUT  DD  DSN=NSR. SOURCE. AMK. TAPE, VOL=SER=XXXX, 
UNIT=TAPE9 , 

11.  //  LABEL-f2,SL) ,DCB=(RECFM=U,BLKSIZE=4000) ,DISP= 
(OLD, KEEP 

12.  //OUTPUT  DD  DSN=&RLCL6IN,DISP=(NEW,PASS) ,UNIT= 
TEMP, 

13.  //  DCB=(RECFM=FB,LRECL=80,BLKSIZE=4000) ,SPACE= 
(4000  ,(5,5)  ) 

14.  //  EXEC  FHL,LM0D='Q1.Q2,AUDITBIN(AUD) ' ,DSP=NEW, 
DEV=SAVE , 

15.  //  TIME=(5,0) , REGION. F=250K,PARM.L=MAP, REGION, L= 
200K 

16.  //F. SYSPRINT  DD  OUTLIM=20000 

17.  //F.SYSIN  DD  DSN=& AUDITBIN , DISP= ( OLD , DELETE ) 

18.  //L.SYSLMOD  DD  SPACE= ( 3 1 56 , ( 600 , 50 , 1 5 ) ) 

19.  //  EXEC  FHL,PARM.L=MAP,LMOD=’Ql.Q2.RLCLBIN(ROLL) ' , 
DSP=NEW,DEV=SAVE 

20.  //F.SYSIN  DD  DSN=& RLCLB I N , DI SP= ( OLD , DELETE ) 

21.  //L.SYSLMOD  DD  SPACE= ( 100 , ( 10 , 10 , 10  ) ) 

22.  /* 


cP 


EXPLANATION  OF  CARDS 


2 . 

4.-5. 

6.-7, 

8. 

10.-13. 

14.-15, 


17. 
18  . 
19. 

20  . 
21  . 


Call  the  utility  CSDS  (copy  sequential  data  set)  to 
copy  the  audit  mode  source  from  tape. 

Describe  the  input  data  set,  which  is  the  source 
tape.  XXXX  is  the  volume  serial  number  of  the  tape. 
Describe  the  output  data  set,  which  will  be  a temp- 
orary data  set. 

Call  the  utility  CSDS  to  copy  the  roll  call  mode 
source  from  tape. 

Same  as  4-7. 

Call  the  FHL  catalogued  procedure  (H  compile  and  link 
edit)  to  create  the  audit  load  module  which  is  to  be 
catalogued . 

The  audit  source  is  input  to  the  compiler. 

Allocate  space  for  the  audit  load  module. 

Call  the  FHL  catalogued  procedure  to  create  and  cata- 
log the  roll  call  load  module. 

The  roll  call  source  is  input  to  the  compiler. 
Allocate  space  for  the  roll  call  load  module. 


4. 2. 3. 2 Execute  Audit  Mode  from  Cards.  If  the  software  to  be 
examined  is  on  cards,  the  following  sequence  of  cards  is  used 
to  execute  the  audit  mode. 


1.  Standard  IBM  Job  card. 

2.  //  EXEC  PGM=AUD,REGION=250K 

3.  //STEPLIB  DD  DSN=Q1 . Q2 . AUDITBIN , DI SP=SHR 

4.  //FT06F001  DD  S YSOUT=A , DCB= ( RECFM= FBA , LRECL= 1 3 3 , 
BLKSIZE=3458) 

5.  //FT04F001  DD  DSN=Q1 . Q2 . IDFI LE , DISP=SHR 

6.  //FT19F001  DD  DSN=Q1 .Q2 . SYNTXGRF , DISP=SHR 

7.  //FT08F001  DD  DSN=&OUTPT , DISP= ( NEW , DELETE ), UN IT=TEMP , 

8.  //  DCB=(RECFM=FB,LRECL=80,BLKSIZE=3120) ,SPACE=( 3120, 

(10,10) ) 

9.  //FT05F001  DD  * 

10.  Options  Card 

11.  Software  to  be  examined 


12.  /* 


EXPLANATION  OF  CARDS 


2.-3. 


.-8 


Get  audit  binary. 

Assign  the  print  file. 

Assign  the  Interface  Definition 
Assign  the  syntax  graph  file  to 
Assign  temporary  file  for  audit 


file  to 
log ical 
revised 


log ical 
unit  19 
program 


unit  4. 
file. 
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10.  Options  card  is  punched  with  a 1 in  Column  1 and  a 5 
in  Column  5. 

11.  At  least  one  program  unit  is  needed.  Only  one  main 
program  is  permitted. 

4.2. 3. Execute  Auc^it  ^l,pc^e_  from  a Sequential  Tape  or  Disk 
Data  Set.  A sequential  data  set  must  contain  at  least  one 
program  unit.  If  there  is  more  than  one  program  unit,  all 
program  units  must  be  consecutively  stored.  Only  one  main 
program  is  permitted.  If  the  software  to  be  examined  is  on 
a sequential  tape  or  disk  data  set,  the  following  sequence 
of  cards  is  used  to  execute  the  audit  mode. 

I. -8.  Same  as  1-8  of  Section  4.2. 3.2 

9.  Assign  tape  or  disk  sequential  data  set  to  logical 
unit  2 . 

10.  VFT05F001  DD  * 

II.  Options  card 

12.  /* 

EXJPLAN^^^^ 

11.  Options  card  is  punched  with  a 1 in  Column  1 and  a 2 in 
Column  5. 

4 . 2 ._3 . 4__  Execute  Audit  Mode  from  a Partitioned  Disk  Data  Set. 
The  partitioned  data  set  must  contain  at  least  one  program 
unit.  Only  one  main  program  is  permitted  per  execution.  If 
the  software  to  be  examined  is  on  a partitioned  disk  data  set, 
the  following  sequence  of  cards  is  used  to  execute  the  audit 
mode . 

1.  Standard  IBM  Job  card. 

2.  //  EXEC  LISTPCH,LIB='Q1.Q2.NAME' 

3.  //SYSPRINT  DD  DUMMY , DCB= ( REC FM=VBA , LRECL= 1 37 , 
BLKSIZE=3429  ) 

4.  //SYSPUNCH  DD  DSN=& DATA , DI SP= ( NEW , PASS ), UN IT=TEMP , 

5.  //  DCB=( RECFM=FB,LRECL=80,BLKSIZE=3200) ,SPACE= 

( 3200  ,(50,10)  ) 

6.  //SYSIN  DD  * 

7.  MEMBERl 
MEMBER2 


MEMBERn 

8.-14.  Same  as  2-8  of  Section  4. 2. 3. 2 

15.  //FTO2F001  DD  DSN  = S.DATA , DISP=  ( OLD  , DELETE  ) 

16.  //FTO5F001  DD  * 

17.  Options  card 

18.  /* 
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EXPLANATION  OF  CARDS 


2.  Call  the  catalogued  procedure  LISTPCH  to  select  the 
desired  members  from  the  partitioned  data  set.  'Ql. 
Q2.NAME'  is  the  data  set  name.  This  procedure  uses  the 
standard  IBM  utility  lEBCOPY. 

3.  Assigns  the  print  file  data  set. 

4. -5.  Data  set  on  which  the  members  will  reside. 

7.  Data  set  members  to  be  examined,  punched  one  name  to  a 

card  anywhere  on  the  card. 

15.  Logical  unit  2 data  set  on  which  the  members  reside. 

4 . 2 . 3 . 5 Execute  Audit  Mode  and  Roll  Call  Mode  from  Cards. 

When  the  roll  call  mode  is  selected,  the  audit  mode  generates 
a revised  roll  call  program  file  for  the  program  unit  being 
examined.  Therefore,  the  roll  call  mode  must  be  executed, 
along  with  the  audit  mode,  once  per  program  unit.  If  the 
software  to  be  examined  is  on  cards,  the  following  sequence  of 
cards  is  used  to  execute  the  audit  mode  and  the  roll  call  mode 
for  a single  program  unit. 

1.  Standard  IBM  Job  card 

2.  //  EXEC  PGM=AUD,REGION=250K 

3.  //STEPLIB  DD  DSN=Q1 . Q2 . AUDITB IN , DI SP=SHR 

4.  //FT06F001  DD  SYSOUT=A,DCB=( RECFM=FBA, LRECL=133 , 
BLKSIZE=3458) 

5.  //FT04F001  DD  DSN=Q1 .Q2 . IDFILE,DISP=SHR 

6.  //FT19F001  DD  DSN=Q1 . Q2 . SYNTXGRF , DISP=SHR 

7.  //FT08F001  DD  DSN=&OUTPT , DISP= ( NEW , PASS ), UNIT=TEMP , 

8.  //  DCB=(RECFM=FB,LRECL=80,BLKSIZE=3120) ,SPACE= 

( 3120, ( 10,10)  ) 

9.  //FT09F001  DD  DSN  = i,  LISTl , DISP=  ( NEW , PASS  ),  UNIT=TEMP  , 

10.  //  DCB=(RECFM=VBS,BLKSIZE  = 100)  ,SPACE=( 100,  (10,10)) 

11.  //FT05F001  DD  * 

12.  Options  Card 

13.  Program  Unit 


14.  //  EXEC  FHLG,PARM. L=MAP 

15.  //F.SYSIN  DD  DSN=&OUTPT , DISP= ( MOD , DELETE ) 

16.  //L.DDl  DD  DSN=Q1.Q2.RLCLBIN,DISP=SHR 

17.  //L.SYSIN  DD  * 

18.  INCLUDE  DDl(ROLL) 

19.  ENTRY  MAIN 

20.  //G.FT09F001  DD  DSN=& LISTl , DISP= ( OLD , DELETE ) 

21.  //G.FT03F001  DD  DSN=& LIST2 , DISP= ( NEW , PASS ) , UNIT=TEMP, 

22.  //  DCB=(RECFM=VBS,BLKSIZE=100) ,SPACE=(100, (10,10) ) 
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23. 

//G.FT03F002 

DD  DSN  = S,LIST3,DISP=(NEW,PASS)  ,UNIT=TEMP, 

24. 

Same  as  22 

25. 

//G. FT03F003 

DD  DSN=&LIST4,DISP=(NEW,PASS) ,UNIT=TEMP, 

26. 

Same  as  22 

(for  temporary  data  sets  4 through  12) 

45. 

//G.FT03F013 

DD  DSN=&LIST14,DISP=(NEW,PASS) ,UNIT=TEMP 

46  . 

Same  as  22 

47  . 

//G. FTlOFOOl 

DD  DSN  = 5,X1  ,DISP=(NEW,PASS) 

,UNIT=TEMP, 

48  . 

//  DCB=( RECFM=FB,LRECL=80 ,BLKSIZE=3120 ) 

,SPACE=( 3120  , 

(10,10) ) 

49. 

//G. FTllFOOl 

DD  DSN=&Y1 ,DISP=(NEW,PASS) 

,UNIT=TFMP, 

50  . 

Same  as  48 

51. 

//G. FT12F001 

DD  DSN  = S.Zl  ,DISP=(NEW,PASS) 

,UNI''’=TEMP, 

52. 

Same  as  48 

53. 

//G.FT13F001 

DD  DSN=&X2,DISP=(NEW,PASS/ 

,UNI'i=TEMP, 

54  . 

Same  as  48 

55. 

//G. FT14F001 

DD  DSN=^Y2,DISP=(NEW,PASS) 

,UNIT=TEMP, 

56  . 

Same  as  48 

57. 

//G. FT15F001 

DD  DSN=&Z2,DISP=(NEW,PASS) 

,UNIT=TEMP, 

58. 

Same  as  48 

59  . 

//  EXEC  PGM= 

lEBPTPCH 

60  . 

//SYSPRINT  DD  SYSOUT=A 

61  . 

//SYSUTl  DD 

DSN  = S.X2  ,DISP=( OLD,  DELETE) 

62. 

//  dd 

DSN=&Y2 ,DISP=( OLD, DELETE) 

63. 

//  DD 

DSN=&Z2 ,DISP=( OLD, DELETE) 

64  . 

//SYSUT2  DD 

SYSOUT=A,DCB=( RECFM=FBA,LRECL=121 , 

BLKSIZE=3509  ) 

65. 

//SYSIN  DD  * 

66. 

PRINT 

MAXFLDS=1 

67. 

RECORD 

FIELD=(80,  , ,5) 

68. 

/* 

Note : Cards  47-67  are  used  only  for  a value  of  2 in 

column  1 of  the  options  card. 


EXPLANATION  OF  _C^RI^ 


1.-8. 

Same  as 

1-8  of 

Sect  ion  4 . 2 . 3 . 2 . 

9.-10. 

Assign 

a data 

set  for  the  audit  mod 

ule 

list 

( Sect  ion 

3. 2. 2. 2 

) . 

12. 

Opt  ions 

card  i 

s punched  with  a 2 or 

3 

in  Col 

umn  1 and 

a 5 in 

Column 

5. 

13. 

Program 

unit  m 

ust  be  a root  program 

un 

it  of 

a module. 

14. 

Call  th 

e FHLG 

catalogued  procedure 

to 

comp  i 1 

» , link 

edit,  and  execute  the  revised  roll  call  program  f.le. 
15.  Declare  the  data  set  S.OUTPT  as  input  to  the  FOKl '’AN 

compiler.  This  data  set  is  generated  by  the  roll  call 


< 
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16  . 

17,-19. 
20  . 

21.-52. 
5 3 .-58  . 


59.-67. 


source  and  contains  the  main  proqram  ROliCAI.  and  the 
revised  proqram  unit  (containinq  calls  to  ROhCHK). 
Declare  the  roll  call  source  as  input  to  the  link 
editor. 

Link  editor  input  cards. 

Declare  the  audit  module  list  data  set. 

Declare  temporary  data  sets.  (Cards  47-52  used  only 
tor  a value  of  2 in  column  1 of  the  options  card). 
Declare  roll  call  output  data  sets  which  are  the  con- 
tents of  SESCOMP  I/O  units  X,  Y,  and  Z.  (Used  only 
for  value  of  2 in  column  1 of  options  card). 

Display  the  contents  of  I/O  units  X,  Y,  and  Z (Used 
only  for  value  of  2 in  column  1 of  options  card). 


In  order  to  execute  the  audit  mode  and  the  roll  call  mode  from 
cards  for  more  than  one  program  unit,  it  is  best  to  run  each 
program  unit  as  a separate  job  since  it  is  more  complicated  to 
execute  several  program  units  in  a single  job. 


4 ^2  . ^.  6 ^xec_ute  Aujdit  Mq^c^e__a_nd  ^Rol_l  C_al_l  Mod_e  _^r  om^_a  Parti- 
tioned Disk  Data  S^t.  When  the  roll  call  mode  is  selected, 
the  audit  mode  generates  a revised  roll  call  program  file  for 
the  program  unit  being  examined.  Therefore,  the  roll  call 
mode  must  be  executed,  along  with  the  audit  mode,  once  per 
program  unit.  If  the  software  to  be  examined  is  on  a parti- 
tioned disk  data  set,  the  following  sequence  of  cards  is  used 
to  execute  the  audit  mode  and  the  roll  call  mode  for  a single 
program  unit. 


1.-6.  Same  as  1-6  of  Section  4. 2. 3. 4 

7.  MEMBERl 

8. -16.  Same  as  2-10  of  Section  4.2. 3,5 

17.  //FT02F001  DD  DSN  = 6.DATA  , DISP=  ( OLD  , DELETE  ) 

18.  //FT05F001  DD  * 

19.  Options  Card 

20. -74.  Same  as  14-68  of  Section  4.2. 3.5. 


In  order  to  execute  the  audit  mode  and  the  roll  call  mode  from 
a partitionec  data  set  for  more  than  one  program  unit,  it  is 
best  to  run  each  program  unit  as  a separate  job  since  it  is 
more  complicated  to  execute  several  program  units  in  a single 
job . 

4 ._2  . ^._7 l^xec_u_te  _Ai^d_i  t Mpd^^  ^nd^  V^r  i^^bl^^  Mode  from 

Cards.  The  variable  precision  mode  processes  an  entire  execu- 
table program.  If  the  executable  program  to  be  examined  is 
on  cards,  the  following  sequence  of  cards  is  used  to  execute 
the  audit  mode  and  the  variable  precision  mode  for  a single 
bit  configuration. 

I.-IO.  Same  as  1-10  of  Section  4.2. 3.2  (but  change  DELETE 
to  PASS  on  card  7) 
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11.  Executable  prcjram  (without  data  cards) 


12.  //  EXEC  EtlG 

13.  //F.SYSIN  DD  DSN  = i.OUTPT  , 0 1 S P=  ( MOD  , DELETE  ) 

14.  //  DD  * 

15.  Variable  precision  function  subprograms 


16.  //G.SYSIN  DD  * 

17.  Data  cards  for  executable  program 


18 .  /* 

EXPLANATION  OF  CARDS 


11.  Executable  program  (without  data  cards)  must  contain  a 
main  program. 

12.  Call  the  FUG  catalogued  procedure  to  compile  and 
execute  the  executable  program. 

13.  Compile  the  revised  variable  precision  program  file 
which  is  generated  by  the  audit  mode.  This  file 
contains  references  to  the  variable  precision  function 
subprog  r ams . 

14. -15.  Compile  the  variable  precision  function  subprograms 

(QlREAL,  QlDPRE,  and  QICOMP)  for  the  particular  bit 
con ; igur a t ion  desired. 

17.  Data  cards  for  executable  program.  If  additional  data 

is  on  tape  or  disk,  the  user  must  make  such  data  avail- 
able to  the  executable  program. 

The  following  sequence  of  cards  (which  includes  cards 
identified  in  the  previous  sequence)  is  used  to  execute  the 
audit  mode  and  the  variable  precision  mode  from  cards  for  more 
than  one  ))it  configuration. 

Cards  1-10 

Executable  program  (without  data  cards) 

Card„  12-14 

Variable  precision  function  subprograms  1 
16-17 

Cards  12-14 

Variable  precision  function  subprograms  2 
16-17 

. (for  additional  bit  configurations) 

/*’ 
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4 . 2 . 8 I^xGC_ute  Audit  Mode  and  Var  iab]^e_  Pi^ec^is  i_or^  Mode__^rorn 

a Seg^uent  ^al  _Ta_pe  jD_r_  _D  i sk  Data  Sj?t,  the  vai  iable  precision 
mode  processes  an  entire  executable  program.  IE  the  executable 
program  to  be  examined  is  on  a sequential  tape  or  disk  data 
set  and  data  is  on  cards,  the  following  sequence  of  cards  is 
used  to  execute  the  audit  mode  and  the  variable  precision  mode 
for  a single  bit  configuration. 

l.-ll.  Same  as  1-11  of  Section  4. 2. 3. 3 (but  change  DELETE 
to  PASS  on  card  7 ) . 

12.-18.  Same  as  12-18  of  Section  4.2. 3.7. 

The  following  sequence  of  cards  (which  includes  cards 
identified  in  the  previous  sequence)  is  used  to  execute  the 
audit  mode  and  the  variable  precision  mode  from  a sequential 
tape  or  disk  data  set  (executable  program  on  file  and  data  on 
cards)  for  more  than  one  bit  conf  iaurat  ion . 

Cards  1-11 

Cards  12-14 

Variable  precision  function  subprograms  1 

16-17 

Cards  12-14 

Variable  precision  function  subprograms  2 

16-17 

. (for  additional  bit  configurations) 

/* 

4 . 2 . 3 . 9_  ^xec_u_t^  Ai^d^t  Mode  and  Variable  Precision  Mode  from  a 
Partitioned  Dis_k  Data  Set.  The  variable  precision  mode  pro- 
cesses an  entire  executable  program.  IE  the  executable  program 
is  on  a partitioned  disk  data  set  and  data  is  on  cards,  the 
following  sequence  of  cards  is  used  to  execute  the  audit  mode 
and  the  variable  precision  mode  for  a single  bit  configuration. 

1.-17.  Same  as  1-17  of  Section  4. 2. 3. 4 (but  change  DELETE 
to  PASS  on  card  13) 

18.-24.  Same  as  12-18  of  Section  4.2. 3.7. 

E X P L AN  AT  I_0_N 

7.  The  data  set  members  must  together  make  up  an  executable 
program.  One  member  must  be  a main  program. 

The  following  sequence  of  cards  (which  includes  cards 
identified  in  the  previous  sequence)  is  used  to  execute  the 
audit  mode  and  the  variable  precision  mode  from  a partitioned 
disk  data  set  (executable  program  on  file  and  data  on  cards) 
for  more  than  one  bit  configuration. 
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Cards  1-17 
Cards  18-20 
Variable  precision 
22-23 

Cards  18-20 
Variable  precision 
22-23 


function  subprograms 


function  subprograms 


(for  additional  bit  configurations) 


4.3  Ver i f icat ion . For  each  program  unit  examined,  AUDIT  prints 
out  any  deviations  from  the  SESCOMP  standards.  Most  of  these 
deviations  must  be  corrected  if  the  program  unit  is  to  conform 
with  the  SESCOMP  standards.  However,  the  flow  analysis  issues 
diagnostics  that  must  be  verified.  A variable  is  indicated  as 
being  referenced  but  not  defined  along  some  path.  The  flow 
analysis  merely  indicates  a possible  undefined  variable.  To 
determine  whether  or  not  the  particular  path  can  be  taken  and 
whether  or  not  the  variable  along  the  path  is  actually  refer- 
enced and  undefined,  this  path  should  be  analyzed  by  the  user. 

4 . 4 _ Spec ial _Ma intenance  Pr og r ams . 

^.4.1^  Program  SESLIST.  The  Interface  Definition  file  (Section 
3. 2. 1.3)  is  created  by  program  SESLIST,  which  reads  card  input 
and  creates  a tape  or  disk  file.  SESLIST  reads  the  input  cards, 
packs  the  card  images,  and  writes  them  out  unformatted  onto 
logical  unit  4.  The  file  should  be  saved  for  later  use  by 
AUDIT.  Each  time  the  Interface  Definition  file  is  to  be  changed, 
SESLIST  must  be  executed.  Section  3. 2. 1.3  contains  a description 
of  the  Interface  Definition  file  and  the  card  input  for  SESLIST. 

4.4.2  Program  GRAPH.  The  syntax  graph  file  (Section  3. 2. 1.4) 
is  created  by  program  GRAPH,  which  reads  card  input  and  creates 
a tape  or  disk  file.  GRAPH  reads  the  input  cards  and  writes  the 
syntax  graph  as  an  unformatted  file  onto  logical  unit  4.  The 
user  need  not  concern  himself  with  the  card  data  used  to  con- 
struct the  file.  Since  the  data  remains  constant,  the  user 
need  only  create  the  file  once,  by  executing  GRAPH.  Sections 

2.1.5  and  3.2. 1.4  contain  a description  of  the  syntax  graph. 

4.5  Error  Conditions.  The  designers  of  the  AUDIT  software 
have  assigned  sizes  to  many  of  the  arrays  so  that  core  storage 
will  not  be  overburdened.  Reasonable  limits  were  chosen  so 
that  most  software  could  be  examined  without  any  array  overflow. 
It  is  possible,  however,  that  some  software  may  cause  an  array 
overflow.  In  this  case  the  array  size  would  have  to  be  changed 
so  that  the  software  could  be  processed  properly.  When  an 
array  overflows,  a message  is  printed  indicating  the  type  of 
the  array.  In  most  cases  AUDIT  processing  then  terminates. 
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If  the  DO  stack  array  overflows,  the  DO  loop  processing  termi- 
nates but  the  rest  of  the  processing  continues.  If  an  array 
overflows  during  the  flow  analysis,  the  flow  analysis  termi- 
nates but  the  rest  of  the  processing  continues.  Following  are 
the  arrays  to  be  watched  for  possible  overflow  during  pro- 
cessing. 

1.  Basic  block  table  - I BLOCK ( 2500 ) in  COMMON  block 
BASBLK . 

2.  Symbol  table  - IDTBL(8,500)  or  I DTBL ( 1 1 , 500 ) in  blank 
COMMON . 

3.  DO  Stack  - 1STACK(4,50)  in  COMMON  block  DOLOOP. 

4.  Branch  list  - ISTCK(IOO)  in  SUBROUTINE  FLOWCK, 

5.  Block  list  - FLWLST(IOO)  in  SUBROUTINE  FLOWCK. 

6.  GIRS  memory  - NODSPC(IOOO)  in  COMMON  block  LVVTRl 

LSTSPC(IOOO)  in  COMMON  block  LVVTR2 

LNKSPC(IOOO)  in  COMMON  block  LVVTR3 

FLGSPC(IOOO)  in  COMMON  block  LVVTR4 

7.  Subroutine  table  - ISUBS(IOO)  in  COMMON  block  GLOBAL 

8.  External  reference  table  - EXTTBL(IOO)  in  COMMON 
block  GLOBAL. 

9.  COMMON  block  table  - BLKTBL(200)  in  COMMON  block 
GLOBAL. 

10.  Statement  number  table  - STATRA ( 2 , 200 ) in  COMMON 
block  LABELS. 

11.  Statement  reference  table  - IFNCRA(5,12)  in  COMMON 
block  FUNC. 

12.  Statement  reference  location  table  - FNCLOC(5)  in 
COMMON  block  FUNC. 

13.  Expression  variables  table  - IARGS(50)  in  COMMON 
block  FUNC. 

14.  Statement  function  table  - ISTFNC(IO)  in  COMMON 
block  STFUNC. 

15.  Interface  Definition  file  tables  - ISUBLT( 2 , 200  ) , 
ISUBLT(  3 , 200  ) , or  ISUBLT( 4 , 200 ) and  INTFAC(300), 
INTFAC(500),  or  INTFAC(600)  in  COMMON  block  LIST. 

16.  Encoded  expression  table  - STR(500)  in  COMMON 
block  STRING. 

17.  Equivalence  table  - IQUIV(lOO)  in  SUBROUTINE  CHKLST. 

The  subroutine,  external  reference,  and  COMMON  block 
tables  are  global  tables  which  store  information  on  all  the 
program  units  being  examined.  All  other  arrays  store  infor- 
mation for  a single  program  unit  and  are  reused  for  each  new 
program  unit  being  examined. 
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Interface  Definition  File 


• flS  1 1 «. 

103 

orRoot  B 0 1 

1 00  100  100  100  1 00  ICO  RC?  <>03 
»EB001  3 0 7 31 

3 1 1 <•  18  1 

BEROSB  901 

103  1 00  ICO  100  100  100  100  <*C3  403 
BEROSI  307  8 

7 1 14 

BIRBG  114 

303 

BIMT  114 

103 

BLCG  114 

103 

BLOGIO  1 1 4 

103 

BHBXO  -1  1 4 
403 

BHBXl  -1  1 4 
103 

BHINO  *114 
403 

BHINl  '114 
103 

BMCO  314 
103  103 
BP40GB  801 

110  110  110  110  110  no  403  403 
BR40GC  107  60 

60  1 

BPPNOG  307  363 

14  300  1 61  4 

BSEOV  6 1 3 
103  103  403  431  403 
BSEOVl  008 
BSELG  4 1 3 
103  403  431  403 
BSELGl  008 
BGELl  008 
BSELIO  4 1 3 
103  403  431  403 
BSERT  413 
103  403  431  403 
BSERTl  008 
BTBN  1 1 4 
103 

BTBN3  314 
103  103 

SBPVBl  107  3 

3 1 

aiNBLK  1 0 I 

403 

BHCO  307  3 

11  1 * 

80MSLB  9 0 1 

100  100  ICO  100  100  100  100  403  403 


BOttSll  3 

0 T 

1 4 

96  1 

? 6 

flOHSlC  1 

0 7 

60 

40  1 

fKBCJJ}lNO  PAUK  BUMUXoOT  ni>ib 


C«BS  1 1 

?0? 

CCOS  1 ? I. 

70? 

CE»P  1 ? <> 

?0? 

CGLOC  10  7 ? 

? 1 

CIOG  1 ? !• 

?0? 

CBOLX  ? ? fc 

10?  10? 

CClEt/i  0 0 1 
cetuMh  107  ? 

? 1. 

CONINP  507  30 

?1  ?G  111  !<•  ??1 

CONJG  1 ? <• 

?0? 

cos  1 1 <• 

10? 

CSIN  1 ? I. 

?s? 

CSQPT  1 ? <> 

?0? 

DABS  1 3 <• 

30? 

OA3AN  1 3 ■> 

10? 

OATAN?  ? 3 

30?  30? 

OBIE  1 3 <• 

10? 

OCOS  1 3 k 

30? 

DF7P  1 3 ii 
30? 

OIK  ? 1 A 

10?  10? 

01 OG  ISA 
30? 

OLOGIO  1 3 

30? 

ONAXl  -1  3 ii 

30? 

OBINl  -1  3 A 

30? 

OHCO  ? 3 A 
10?  30? 

OSEOV  53? 

30?  30?  AO?  A?1  AO? 

0SCD51  000 
OSUG  A3? 

30?  AO?  A?1  AO? 

OSCLGl  000 
05CL1  0 0 0 

OSELIO  A3? 

30?  AO?  A?1  AO? 

OSEPT  A3? 

30?  AO?  A?1  AO? 

OSEPTl  000 
OSIGN  ? 3 A 
30?  30? 

OSIN  1 3 A 
30? 

OSOPT  1 3 A 
30? 
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OUHB  107  1 

1 % 

eNGiNA  3 0 3 
10?  AO?  AO? 


ENGINt 

8 

0 

7 

1507 

0 

A 

?0O 

1 7 A 7 1 

?1  A 1176  1 

1 A 

? 1 

EQNCO 

? 

0 

7 

A1 

1 

A 

AO 

1 

E*P 

1 

1 

A 

10? 

FANA 

7 

0 

1 

10?  11? 

110 

100 

100  AO?  AO? 

fanota 

3 

0 

3 

110  AO? 

AO? 

FAMI 

S 

0 

7 

35A 

?1 

A 

80 

1 AS  A 70S  1 

3 A 

FGIA  6 1 ? 

10?  AO?  11?  11?  AOl  AO? 

TG?A  10  1 ? 

10?  10?  AO?  AO?  11?  11?  1??  AOl  AOl  AO? 
fLAGS  10  7 A 

A A 

FLOAT  1 1 A 
AO?  ( 

FROUOE  107  ? 

2 1 


FTNBtM 
AO?  AO? 

3 0 
Al? 

0 

GBOW 

3 

1 0 

1 

7 

3 

MELHS 

3 0 

7 

A09 

8 

A AOO 

1 t A 

TAPS 

AO? 

1 A 

A 

IOI« 

AO?  AO? 

? A 

A 

lOINT 
10?  , 

1 A 

A 

IFII 

10? 

1 A 

A 

I NCOAA 
100  AOO 

3 0 
AOO 

3 

INCUT 

0 0 

6 

INT 

10? 

1 A 

A 

INTGRA 

7 0 

1 

AO?  11? 

10? 

11? 

AO?  ACt  AO? 

ISEOV 

5 A 

? 

AO?  AO? 

AO? 

A?l 

AO? 

ISEOVl 

0 0 

8 

ISECO 

5 A 

? 

AO?  AO? 

AO? 

A?1 

AO? 

ISICN 
AO?  AO? 

? A 

U 

leaker 

1 

1 0 

1 

7 

1 

lqaos 

1 

1 0 

1 

7 

1 

NA5SES 

? 0 

7 

1006 

1 

^ 100$ 

1 

NATRII 

36 

1 0 

1 

7 

36 

N AlO 
AO? 

-1  A 

A 

NAll 

•1  A 

A 

10? 


KIN«*  611 

171  «07  100  «ll  «10  «07 

NINO  -INN 

NI7 

NINl  -INN 
117 

NOO  7 N N 
N07  N07 

NStOM  117  79 

79  1 

NMIVC  117  6 

• 1 

OPTION  117  1 

3 N 

PlGCl  000 
PMTCON  107  7 

7 1 

PRINT  117  3 

3 N 

PROP*  111 

111  111  101  111  100  101  N07  N07 
PROPI  717  8 

7 1 IN 

RCIL  1 1 N 

717 

RMS*  313 

117  111  N07 
ROLCOL  901 
NOl  N77  ND7  N17  N17 
SON  711 

N07  N07  107  117  107  N07  N07 

SEGOl  10  0 

SCSI  0 0 9 

SCSBT  NOl 

N07  N77  N07  NO? 

SESCON  707  79 

13  0 1?  N 

SESPLl  301 
N07  NO?  NO? 

SIOTOO  009 
SIOMLO  1?  0 1 

107  NO?  100  100  100  100  100  100  100  NO  7 107  NO? 
SIOMll  3 0 7 77 

IN  79  1 IN 

SIGN  7 1 N 

107  107 
SIN  1 1 N 

107 

SLOPE  117  7 

7 1 

SNGL  1 1 N 

307 

SPMT  N 0 7 99 

IN  9 1 IN  NO  1 

SPPORG  107  1 

1 1 

SORT  1 1 N 

107 

ST  OPT  10  6 

STNSL*  901 

100  100  100  100  100  100  110  NO?  NO? 

STNSL 1 317  30 

IN  70  1 IN 

STNSL 0 107  NO 

NO  1 


122 


4 


TAN 

1 

1 

k 

102 

TANH 

1 

1 

4 

10? 

times 

1 

0 

7 

5 

5 

1 

TOeOUE 

0 

0 

q 

TPACEl 

0 

0 

0 

TPAP 

? 

1 

? 

11?  40? 

UNITS 

1 

0 

7 

q 

S 

4 

USEOOl 

0 

0 

0 

USEOO? 

0 

0 

0 

USE003 

0 

0 

0 

USEO04 

0 

0 

0 

USED06 

0 

0 

0 

USEO06 

0 

0 

0 

USEOlO 

0 

0 

0 

USEOll 

0 

0 

s 

USE014 

0 

0 

0 

USEOIT 

0 

0 

0 

USEOlO 

0 

0 

0 

USE019 

0 

0 

0 

USE0?0 

0 

0 

0 

¥AffPLE 

1 

0 

7 

15 

15 

1 

HAVE 

1 

0 

7 

6 

6 

1 

HAVEA 

11 

0 

1 

40?  11? 

11? 

no 

no  no  no 

no  no  40?  40? 

MAVESI 

4 

0 

7 

79 

1 

1 

1 

4 7f>  1 

1 4 

HA VTAB 

6 

0 

7 

14050 

1 

4 

? 

1 1 4 

? 1 14 

XYZTAB 

1 

0 

7 

051 

051 

1 

1 k 1<*040  1 
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Audit  and  Flow  Analysis  of  a Main  Program 


C OPTION  1 SAHPtE  MAIN  PP06PAM,,,,«iESCOMP.US-0?-060l76 

C CATEGORY  1 labeled  COMMON 

c 

c 

c >MM0N/SESC0M/CAS£  ( 13)  # INA*  INBf  INCt  IOA  »NP  AGX  . L I NX  1 1 0 Y tNPAr,  y ,L  I Nv  , I O7  «NPA«r  ,L  I NT 

C 

C 

C CATEGORY  ? LABELED  COMMON 

C 

C 

C CATEGORY  3 LABELED  COMMON 

C 

C 

1 F0RMATn3AA,l4) 

? format (5X»5?H0PTI0N  1 SAMPLE  MAIN  PROGRAM. St SCOMP . US-0?-nfte 1 Tfr ) 

3 FORMAT (14) 

C CASE  LOGIC 

call  INOOT 

call  inout 


REA0(INA,3)  NCASE 


GRAPH  HAS  BEEN  PLACED  INTO  MEMORY 


00  A I'l.NCASE 

REAOdNA.U  CASE, MODE 

CALL  START 
CALL  start 

CALL  XAMPLdERR.l) 

HARNING  - THIS  MODULE  IS  NOT  IN  THE  SESCOMP  LIST 
CALLXAMPL ( lERR, I ) 

call  SESPLI (IOX. 1 ,?) 

CALLSESPLIdOX.1,2) 

mRITE (IOX.?) 

call  XAMPL (IERR.moOE) 

CALLxAMPLdERR.MOOE) 

IF  ( IERR.E(3.0)  GO  TO  S 

CA^L  inout 
call  inout 

4 CONTINUE 


9 STOP 


Symbol  tablc  foa  module  main 
variables 


NAME 

type 

RELOCAT 

CASE 

REAL 

ARQAY  1 

SESCOM 

INA 

tNTEOER 

sEscom 

lOI 

integer 

sescom 

NCASE 

integer 

I INTEGER 

mode  integer 

lERR  INTEGER 


NAME 

Externals 

TYPE 

ARCS 

INOUT 

0 

start 

0 

»ampl 

? 

SESPLI 

3 

statement 

LABELS 

1 2 

3 4 

common 

BLOCKS 

NAME 

length 

SESCOM 

i I 

i 

I 

n' 

■ results  of  flow  analysis 


NO  ERRORS  FOUND 


NUMBER  OF  PATHS  CHECKED-  ? 


I2h 


d 


Audit,  Flow  Analysis,  and  Roll  Call  (Mode=^2)  of  a Sjjbroutine  Module 


SU*^RnuTINC  aPNOGA  <FX,rY,F7,FK,FM,PN,ION,*lOOf  ) 


C 


CflTF&ORX  1 COMMON  BLOCKS 


common  /APNOGO/  K4PPF ( ^0 ) ,V ftPPF { 201  , ZAPPF { ^Q > 


COMMON  /APpnCG/  NflPP,xapP{?0),YAPPC20),ZftPP(?0)  ,CMOT (^0I^CMOP|?0>•SPAN(20) ,TOVC(20  > * ANGINC<20I 
, ANGCNT  (?0»  t ANGSHP  <?0l,ILIFT(?D),IATT<20»tITVPE(?0)« I APNOG 


common  /CGLOC/  xs,zs 

COMMON  /flags/  ijor , icasf , tstep, ifqp 

COMMON  /PmyCON/  g,rmo, mrho* CNU*«H0INF, pi nf , gam 

COMMON  /SESCOM/  CASE  ( I 3)  , INA,  IN8,  iNCt  IOX,NPAf,X,LlNX,  lOY  ,NPAG'r,LINY,  10Z,NPAGZ,LINZ 
COMMON  /YARRLf/  VALdSJ 

C •••«•*«•••«»•*•••«  CATEGORY  2 COMMON  BLOCKS  ••••••••••••••••#• 

COMMON  /USEO03/  MUSE 

C 

1 FORMAT  (44X,S?MSURR0UTI  NE  APNOGA DRAFT.  01-01-0514741 


C 

2 FORMAT 

3 FORMAT 

4 FORMAT 
CONTINUES.! 

5 FORMAT 


n?H  •••ERROR***! 

(5X.12HUSF  INOFX  IS. I J*21M  CHECK  INITIALIZATION! 

(5*.2<.H  IMPROPER  MODE  INijfX  OF  ,I4,13M  E NCOUNT EREO . /5* , 3 9H  ZERO  SUBSTITUTED. 
(5K.5HUSFO  .I5.40M  TIMES  WITH  MODE  INDEX  GREATER  THAN  ZERO! 


ROLL  CALL 


6 


FORMAT  (/9H  APNOGA  /120H  APNOG  ANG  INC  CANT  ANG 


X-FORCE 


y-FORCE 


Z-FORCE 


90LL  HON,  PITCH  MOH,  YAM  NOH,  /^^0H  HO.  OCG.  OCG.  IBS. 

lbs.  lbs.  FT-LBS.-  FT-LBS.  FT-LBS.  /I 

7 F09HAT  (I4,3F10.?.6E16.<»> 

OIHENSION  FV(1).  FYID*  FZU)«  FKlUf  FH(H,  FNItl 
OIHEHSION  RCOStZOI,  RSXNI20) 

OIHENSION  ETAtZm.  VWAVEIZOI*  NMAVEtZOI.  DUHCZOI 

equivalence  (VALIZI.UI.  (VAL(3l,V)t  (VALU)«M),  IVALC9)«P>t  (VAL(6I,Q).  TVALfFttRI*  (VAl(SI.Ph 
II*  <VAL<9>tTHETA)  • fVAU10l«Z» 

C CHECK  HOOF 

IF  (NOOE.LT. 1»  GO  TO  17 

graph  has  seen  places  into  NENORT 

NUSE«HUSE*l 

HUSE»NUSE»1 

C beginning  Of  JOB  LOGIC 

IF  UJOB.EQ.ll  GO  TO  8 

PI>it.«ATAN(l.l 
PI«N.*ATAN(1  .) 

pie-Pi/8. 

PX8-P1/8. 

RAO«180.0/PT 

RAO«160.0/PI 

8 CONTINUE 

C BEGINNING  OF  CASE  LOGIC 

IF  (ICASE.CQ.l I GO  TO  10 

00  9 I«1«NAPP 

RSINIII «SIN( ANGCNT I II I 
RStN(I|aSIN(ANGCNT<III 


128 


4 •COSCI  )*COSMNOCNTI  tit 

4 *00411 l•COS(*NCCNTI III 

II  continue 

Q2»U*U*MltH0 

OE*U»U»M«MO 

C BEGINNING  Of  TINE  STEP  LOGIC 

IE  (ISTEP.EQ.l I GO  TO  It 

CALL  NIVC*  INIPP.IIPP, Y«PP,ET*,OUN, OUH, OUN, VN« VE . NNIVE.  ION, NODE  I 
CILL  ROLCHK  I1HN,1H*,1HV,1HE,1H*,1H  I 

11  continue 

00  14  I*t,NIPP 
C CILCULITE  NETTED  SPIN 

0S**Z»7I-*»PPai»TMET»«y*PP(II»PMI«ET*(II 

os»»z*zs-«»pp«ii  •tmetityippi  n»PMiTET»(i  I 

RSPINaSPINdl 

RSP*N«SP*N(II 

P»»E»*.S» (CMOT (IlaCHOB (II l•*SP»N 
R«*EI>.S«(CH0T II laCHOR (I  I l*RSP*N 

ENOE«C«1.0 
EN0E«C*1 .0 

OELT»OSR-(ZS-Z»PP(III 

OELT*OSR-(ZS-Z*PP(III 

C IS  IPPENOIGE  OUT  OF  NITER 

IF  (OELT.GE.O.II  GO  TO  11 

C IS  IPPENOIGE  HORIZONTIL  OR  CINTEO  UPNIRO 


IF  IRCOSdl.LE.O.OI  GO  TO  17 


RSPINaRSPINtOELT/RCOSdl 
RSPIN>RSPIN*OELT/RCOSI  II 


s~'- 


124 


If  (RSPAN.LC.0.0)  60  TO  12 


ICHDT  fl l♦CHOR  U » •R$PftM/SPAN ( I M *9 SP AN 
RAREA« .S«(CHOT  < I l♦CHOR U I •RSPAN/SPA N II M *RSrAN 


CNOf AC«1.0 
CMnPAC«l,0 


60  TO  IJ 


12  FKIIsO.O 

12  Fxai«0.0 


FYm*0.0 

Fr(ii«o.o 


F2(n«0.0 

F7(II«0.0 


FN(I >sO«0 

FK(n*0.0 


FH(I»«0«0 
FN<n  = o.o 


FN(tl*0.0 

FN(n«0.0 


GO  TO  IN 


c calculate  lift 

13  VM*V*K APP( I } •R-ZAPP (I>  *P-VMAVt (I > 

13  VM«V»*APP<  n •R-ZAPP  n I •P-VWAVE  II > 


VV«W*XAPPf I) •Q4VAPP I II «P4U*THE  TA-MWAVC ( I i 
VV<N-XAPPMI  •Q4TAPP(I  I «P4U*  THE  T A -MM  A VE  ( 1 1 


PHIV«ANCCNT( II 4PHI 
PhIVsAHGCHT (II 4PHI 


VN>$QRT ( VV*VV4VH«VHI 
VN=SQRT ( VV*VV4 VH*VH I 


1 JO 


PHiNsPHiV 
PMIN*PMI V 


I 


IF  (VN.NE.O.OI  PHlNsPHlVrATftN?(VVtyH| 


VN=  VN*CnS 
VN=VN*COS(Pm1n» 


AL  PHA  Is  AT4N?  (VN  , Ul 
ALPHAIsATAN?(VN,U) 


F^  F AMf,s  AMOlNCU)  - ALPHA  I 
FFFAM&sAN&INCf I) -ALPMAI 


OQsQ?*PAREA 

')0sQ^•9AReA 


PFr»U*  <PA9EA/»SPAN> /FNU 
REVsU* (9AREA/PSPAN) /FNU 


CFP».42  7/(ALOGIO  <RE  y>-.40F|  ••2,64 
CFRs,42r/'(ALOG10<P€  Y»  - ,407>  ••2.64 


9ASPP«RSPAN^9SPAN/RA9E A 
PASPR=RSPAN*9$PAN/RARE A 


RCL0*2 . *PI ’RASPR/IR ASPR*  3 ,» 
RCL8=2.*PI*RASPR/IRASPR^3.» 


rLiFTsQQ^f nofac^pclb^effanc 
FLlFT»QQ*€N0FAC*RCL8*f FFANC 


co*2.*cfr4pi Strove « ii •rove* !>•  a.^r.^PSPAN/  <u*u> » ♦rcl8*effanc^£ffanc 

C0a2.*CFR4PX8^T0VCC !»• TOVC* I )• U .♦G^RSPAN/ (U»UU ♦RCLB*£FF ANG»EFFAN 


calculate  moment  arms 


VAPPF ( n >KAPP( I) 
XAPPFm*IAPP(l» 


YAPPF  m>YAPPI  n - (SPAN  m -•^•RSPAN)  •RSINII) 
YAPPFf II«YAPP(I I -(SPAN(XI-.SPRSPAN) •RSXN(I) 


7APPFI II«2APP(|I ♦(SPANII )-,9^RSPANI •RCOS 1 1) ♦ V APPF ( I) •PH  I • XA PPF ( X ) • THE TA 
2APPF( I) «2 APPC II ♦(SPAN(X>-.S«RSPANI •RCOS ( XI • VAPPF ( I I •PH X -X APPf (II* 


FX(|l«-CO»QQ 

FX(XI«-C0*00 


in 


rraMnirr^ffcosai 

Fta»«rLiFT*»cosm 


f 7a»*rLiFT*ffsiNni 
r2m«ruri»QsiNU» 

FMII»-7AP*>f  (II  •Ft!  I I * VAPPf  ( I)  «FZ  u I 
F K(  I •■-ZAPPF  (II  •FT  < I I *TAPPF  ( II  •FZU  I 

FH(I l-Z^POFI II •F<( I I -* APpr ( I |*FZ (11 
FX(I I »ZAPPF I II •Fi( I I -I APPFII I^FZ (II 

FN(I l*-y*PPF (II •FX ( 1 I »KAPPF ( 1 » •FT  (I  I 
FM(II*-T«PPF(II»FX(  IMKAPPFdMFTdl 

lu  CONTiNUe 

IF  (ION.nF.IAPNOGI  PfTU^N 

ITE»1P»5*NAPP 

ITeHP»5*NAPP 

CA'L  StSPLl  (IOX,tTEMP,NOO£l 

CALL  ROLCHK  ( 1 H$ ,1H£ , 1 H$ , IHP * 1 HL t IHl I 

MPITF  (IOX,6l 

DO  15  I»l,NAPP 

ANG1»ANGINC(  II*RAO 
ANG1«ANGINC(  II *RAO 

AHGZMNGCNK  I1«RAQ 
AHG2«ANr.CNT  ( II  *RA0 

MRITF  (lOX.ri  I«ANGl.ANGZ«FX(nfFV(  II,FZ(II,FK(Xl,FM(II  ,FN(II 

15  CONTINUF 
RFTURH 

C START  SrSCOM  ROLL  CALL  COOING  WITHOUT  BUFFER  TRACING 

c path  for  errors 

16  call  SESPLl  (I0X«3«1I 

16  call  ROLCHR  (lHSflHEflHS»lHP,lHLf IHII 


132 


wpiTe  (lox,?) 

M*?ITE  lioir.n 
MRire  nox,3»  husf 
GO  TO  2k 

C POLL  call  coding 

17  NMOO=NODE 

17  NMOOsMOOE 

IF  (MUSE) 

18  IF  (HOOE.GE.-3I  GO  TO  19 

IF  IHOOF.CE.-7I  GO  TO  20 

I0-I07 

IO*IOZ 

IF  (NOOE,GE.-11»  GO  TO  2l 

19  IO>IOX 

19  I0«10X 

IF  (HOOE.GE.-llI  GO  TO  ?1 
CALL  SESPLl  MO«i*,l  I 

CALL  90LCHX  ( 1 H$ * IH C • 1 HS « IHP , 1 HL • IHII 

WRITE  (10*Z) 

WRITE  llOfll 

WRITE  MO,%l  MODE 

NHOO«0 

NHOO«a 

GO  TO  it, 

20  IO«IOY 

70  lo*ior 


1 M 


•W4. 


zx  CAu  sESPLi  ao,i*n 

ZX  CALL  AOLCHK  (1  HS  ,1HC  , t H$«  IHP  * 1 H|.  » IHlI 

MRITE  I10«1I 

NH00F«ISIGNINM00«U  *1 
HNOOC«ISIONfNHOO«ll  ♦! 

INOV>NOO(NNOOE«<i)*l 

|NOX«HOO(NHOCr«SMl 

C CO  TO  SCLECTFD  *100E 

CO  TO  • INOX 

ZZ  CALL  SESPLl  (lO.ltl) 

ZZ  call  90LCHK  U H$ , IHE • 1 MS « IHP , IHL « IN  II 

WRITE  MO»9)  NUSE 

^3  HUSE-0 

?3  HUSE-9 

C CALL  REFERENCFO  NOOOLES  IN  ROLL  CALL  NOOE 

CALL  SESPLl  (lO.lfHOOEl 

CALL  ROLCMX  C 1 H$ , IHE « 1 NS • IHP , IHL • IN 1 1 

CALL  NAVEA  ( ON* ON, ON , OH« OH* OH, ON t ON • OH,OH« NODE  I 


ARCUNE  NT 

NO.  1 NAS 

; INCORRECT 

»99  9 9« 

TYPE 

9999 

marning 

• ARGUHENT 

NO. 

• • • 

z 

9 9 

> 9 

HAY 

999 

9999 

have 

9999 

INCORRECT 

oihensionality 

WARNING 

- ARGUHENT 

NO. 

• •• 

9 9 

3 

• • 

9 99 

HAY 

9 99 

9999 

have 

9999 

incorrect 

OINENSIONRLITY 

WARNING 

• ARGUHENT 

• • • 

NO. 

• •• 

• • 
• • 

9 99 

HAY 

9 99 

9999 

HAVE 

9999 

incorrect 

oihensionality 

WARNING 

• ARGUHENT 

99  9 

NO. 

99  9 

• 9 

5 

• • 

9 99 

HAY 

9 9 9 

99  99 

HAVE 

9999 

INCORRECT 

oihensionality 

WARNING 

- ARGUHENT 

9 99 

NO« 

• •• 

• • 

6 

• • 

9 9 9 

HAY 

9 99 

9999 

HAVE 

9999 

INCORRECT 

OIHENSIONALITY 

WARNING 

- ARGUHENT 

99  9 

NO. 

• • • 

• • 

r 

9 9 

999 

HAY 

9 99 

9999 

NAVE 

9999 

INCORRECT 

oihensionality 

WARNING 

- ARGUHENT 

• • • 

NO. 

>•••• 

9 9 

8 

• 94 

9 99 

HAY 

» 999  1 

9999 

have 

INCORRECT 

oihensionality 

NARNING 


ARGUHfNT  HO 


9 HAY  MAve  incorrect  oihensionality 


SYHeOL  TABLE  FOR  HOOULE  APNOGA 
VARIABLES 


NAME 

f yPE 

RELOCATION 

FX 

REAL 

ARRAY 

1 

F.  P. 

Ft 

REAL 

ARRAY 

1 

F.  P. 

F 1 

REAL 

ARRAY 

1 

F,  P. 

FX 

REAL 

ARRAY 

1 

F.  P, 

FN 

REAL 

ARRAY 

1 

F.  P. 

FN 

real 

ARRAY 

1 

F.  P, 

ION 

INTEGR 

F.  P. 

NODE 

INTEGR 

F,  P. 

XAPPF 

REAL 

ARRAY 

1 

APNOGO 

YAPPf 

real 

ARRAY 

1 

APNOGO  ^ 

Z APPF 

REAL 

ARRAY 

1 

APNOGO 

NAPP 

INTEGR 

APPNOG 

XAPP 

REAL 

ARRAY 

1 

APPNOG 

TAPP 

REAL 

ARRAY 

1 

APPNOG 

ZAPP 

REAL 

ARRAY 

1 

APPNOG 

CHOT 

REAL 

ARRAY 

1 

APPNOG 

CHO^ 

PEAL 

ARRAY 

1 

APPNOG 

SPAN 

REAL 

ARRAY 

1 

APPNOG 

TOVC 

REAL 

ARRAY 

1 

APPNOG 

ANGINC 

REAL 

ARRAY 

1 

APPNOG 

ANGCNT 

REAL 

ARRAY 

1 

APPNOG 

I APN06 

INTEGR 

APPNOG 

zs 

REAL 

CGLOC 

ijoe 

INTEGR 

FLAGS  1 

ICASE 

INTEGR 

FLAGS 

ISTEP 

INTEGR 

FLAGS 

G 

REAL 

PMYCON 

HRHO 

real 

PHYCON 

ENU 

real 

PNYCON 

lOX 

INTEGR 

SESCON 

lOT 

INTEGR 

SESCON 

lOZ 

INTEGR 

SESCON 

VAL 

REAL 

ARRAY 

1 

varble 

HUSE 

INTEGR 

USEOI3 

RCOS 

REAL 

ARRAY 

1 

RSIN 

REAL 

ARRAY 

1 

ETA 

REAL 

ARRAY 

1 

WAVE 

REAL 

ARRAY 

1 

MMAVE 

REAL 

ARRAY 

1 

OUN 

REAL 

ARRAY 

1 

u 

¥ 

H 

P 

Q 

R 

PMI 

thct* 

z 

PI 

Pit 

RAO 

1 

QZ 

OSR 

RSPAN 

RARER 

ENOFAC 

OCLT 

VH 

VV 

PHIV 

VN 

PHIH 

ALPHA! 

E PFANC 

QQ 

REY 

CFR 

RASPR 

RC(.9 

flift 

CO 

XTEHP 

angi 

ANGZ 

NHOO 

10 

NHOOE 

INOX 

OH 


REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

INTECR 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

real 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

REAL 

INTEGR 

REAL 

REAL 

INTEGR 

INTEGR 

INTEGR 

INTEGR 

REAL 


EXTERNALS 

NAME 

TYPE 

«TAN 

REAL 

SIN 

REAL 

COS 

REAL 

NAVE* 

SON! 

REAL 

ATANE 

REAL 

ALOGIO 

REAL 

SESPLl 

ISIGN 

INTEGR 

HOO 

INTEGR 

ARGS 

1 

i 

1 

11 


1 

STATEMENT 

t 

LABELS 

] 

N 

S 

i 

T 

12 

• 

11 

It 

IN 

13 

12 

It 

IG 

2N 

lA 

IB 

M 

21 

2J 

22 

COMMON 

■LOCKS 

NAME 

LENGTH 

APNOGO 

M 

APPNDG 

2G2 

CCIOC 

2 

FLAGS 

B 

PNVCON 

? 

SCSCON 

2t 

VARBLC 

It 

USEOfI 

1 

1 ih 

RESULTS  OF  FLOM  »N»IYSIS 


THE  VARIABLE  OH 

IS 

REFERENCED 

BUT  NOT 

DEFINED 

ALONG  the  path 

17 

18 

19 

23 

THE  VARIABLE  ETA 

IS 

REFERENCED 

BUT  NOT 

defined 

ALONG  the  path 

8 

10 

11 

THE  VARIABLE  VHAVE 

IS 

REFERENCED 

BUT  NOT 

DEFINED 

along  the  path 

8 

10 

11 

13 

The  V8RUBLE  MHtVE 

IS 

REFERENCED 

BUT  NOT 

DEFINED 

ALONG  the  path 

8 

10 

11 

13 

THE  VARIABLE  PI 

IS 

REFERENCED 

but  NOT 

DEFINED 

ALONG  the  PATH 

8 

10 

11 

13 

THE  V»RI»BLE  PIS 

IS 

REFERENCED 

but  NOT 

DEFINED 

ALONG  the  path 

8 

10 

11 

13 

THE  VAPIABLE  RSIN 

IS 

REFERENCED 

but  not 

OEF INEO 

along  THE  PATH 

8 

10 

11 

13 

The  VARIABLE  RCOS 

IS 

REFERENCED 

BUT  NOT 

DEFINED 

ALONG  the  rath 

8 

10 

11 

13 

THE  VARIABLE  RAQ 

IS 

REFERENCED 

but  not 

OEF  [NED 

ALONG  The  path 

8 

10 

11 

13 

IN 

NUMOFR  OF  P»THS  CHECKED-  78 


FLOK  *M»LYSIS  TOOK 


1.394  CP  SECONDS 


I 57 


CI.OBAI  gercKMce  t«bcc 


EXTERNAL 

REFERENCES 

ATAN 

ANSI 

FUNCTION 

SIN 

ANSI 

FUNCTION 

COS 

ANSI 

FUNCTION 

WAVEA 

SUBROUTINE  NODULE 

SORT 

ANSI 

FUNCTION 

ATAN2 

ANSI 

FUNCTION 

AL OGIO 

ANSI 

FUNCTION 

SESPLl 

SUBROUTINE  NODULE 

ISI6N 

ANSI 

FUNCTION 

NOO 

ANSI 

FUNCTION 

LBBELLFO  COMMON  BLOCKS 


BLOCK  HAHE 
APNDGO 
APPNDG 
CGLOC 
FLAGS 
PHTCOM 
SESCOM 
VARBLE 
USED03 


SIZE 

6B 

262 

2 

6 

T 

25 

15 

1 


CLASS 

CATEGORK 

CATEGORY 

CATEGORY 

CATEGORY 

CATEGORY 

CATEGORY 

CATEGORY 

CATEGORY 


SUBROUTINES  ENCOUNTERED 
APNOGA  SUBROUTINE  MODULE 


SU^^ffOUTI  Nt  ftPNOGA  <FX,FV,FZ,FK,FH,FN,ION,  HOOF  I 
COHhON  /APNQGO/  X4PPF < 20 ) , rAPPF  120 > tZAPPF (20 ) 

common  / APPNOG/  NAPP, XAPP(20  » , YAPP(20) , ZAPP(20» .ChOT (20  » tCHOR (20>  . 
•«^PAN(20)  ,TOVC(?0>,ANGINC(20»  ,ANGCNT  (2  0 ) . ANGSMP(20  »•ILIFT(^0»,IATT( 
•20) . I TYP€ ( 20) ♦ I APNOG 
COMMON  /CGLOC/  XS,7S 

COMMON  /flags/  IJOfi.I CASF, ISTEP,  IFRR 

COMMON  /PHVCON/  G«RHO , HRHO • E NU « RHO I NF , P INF , GA M 

COMMON  /SESCOM/  CASE ( 13) * I NA , I NB t INC . 10 X * NPAG X • L I NX t I OY ,NP A&Y , L I NY 
• ,T07 .NPAG2 ,LIN2 
COMMON  /VARBLE/  WAL(15) 

COMMON  /USEO03/  MUSE 

1 FORMAT  (NX,S?HSU8R0UTINE  APnOGA DRAFT.  01-01-051474 

• ) 

2 FORMAT  ( 12H  •••ERROR***) 

3 FORMAT  (5X.12HUSE  INDEX  I$,I3,21H  CHECK  INITIALIZATION) 

4 FORMAT  (5X,?4H  IMPROPER  MODE  INDEX  OF  ,I4,13H  ENCOUN TEREO . /5 X , 39M 

•ZERO  SUBSTITUTED*  ROLL  CALL  CONTINUES.) 

5 FORMAT  <5x,5HUSE0  «I5*40H  TIMES  NITM  MODE  INDEX  GREATER  TmAN  ZERO) 

6 FORMAT  (/AH  APNOGA  /120H  APNDG  ANG  INC  CANT  ANG  X-FORCE 

• Y-F0#CF  Z-FORCE  roll  MOM.  PITCH  MOM. 

• YAM  MOM.  /120H  NO.  OEG.  DEG.  LBS.  L 

*eS.  LBS.  FT-LBS.  FT-L0S.  FT- 

•L9S.  /) 

7 FORMAT  ( I4*2F  10 .?«6f 1 6.4) 

DIMENSION  FX(1),  FV(1),  F2(l),  FK(1),  FM(1),  FNID 
DIMENSION  RCOS(ZO)*  RSIN(?0) 

DIMENSION  ETA(?0),  VMAtfE(20)«  MHAVE(?0)«  DUM(20) 

equivalence  (VAL(2)*U),  (VAL(3)*V)i  (VAL(4)«H>*  (VAL(5)*P)«  (VAL(6 
*),Q),  (VAL(7),P),  (VAL  (8)*PHI) , ( V AL < 9 ) » T HE T A ) * (VAl(10)*Z) 

IF  (MOOE.LT.l)  GO  TO  17 
HUSF*MUSE*1 

IF  (IJO**  EQ.l)  GO  TO  a 
PIs4.«ATAN(1.) 

PiasPi/a. 

RAD>180.0/PI 

8 continue 

IF  (ICASE.EQ.l)  GO  TO  10 

DO  9 1*1 ,NAPP 

RSIN( I)*SIN(ANGCNT(I) ) 

9 RC0S(  I)  sCOSIANGCNT  (in 

10  CONTINUE 
Q2»U*U*HPh0 

IF  (ISTEP.EQ.l)  GO  TO  11 

CALL  ROLCHK  ( IHM , 1 H A, 1 HV* 1 H£ , 1 H A * IH  ) 

11  CONTINUE 

DO  14  I*1,NAPP 

0$R«Z»ZS-XAPP( I) •THET A^VAPP( I)*PHl*ETA(I> 

RSPAN*SPAN(  I) 

RAREA*  .5*(CHOT  (I)  aCHOR  U)  I *RSPAN 
ENDF  AC* l.O 

OELT*OSR-(ZS-ZAPP(  in 
IF  (BELT. GE. 0.0)  GO  TO  13 
IF  (RCOS  (I  I *LE  .0.0  ) GO  TO  12 
RSPAN*RSPANaOELT/RCOS (1) 

IF  (RSPAN.LE.0.0)  GO  TO  12 

RARfA«.5«(CHOT(tl*CHOR(I)*RSPAN/SPAN(I))*RSPAN 


f NOf  1 . 0 
GO  TO  13 

12  F « (I)  *>' . 0 
FT (TJ  *0. 0 
F7  (I) =0 . 0 
FKd'sO.C 
FHMi  sO.O 
F»<(  n *0 . 0 
GO  jr,  i<* 

13  V«=V^  XftPPi  I)  •R-7APPCI  I ♦P-VWAVC:  (I) 

XAPPU  >•Q♦YAPP(n  *P4U*THE  TA-MMAVE  ( I) 

PH  IV*  ANr.CNT  (I  > ♦PHI 
VN-rSQR*  < VV*VV^VH»VH| 

PHIK  PHIV 

IF  (VN.NE.0.0)  PHIN*PHlV“ATAN7t VVtVH) 

VN=VN*C0S<PHIN| 

ALPHAI:ATAN?(VN*U) 

fffang=anginc<i» -alpha  I 

QQ=U? •PARE  A 

REf*U* 1RAREA/RSPAN)/ENU 

CFRs. 4?7/(ALOG10 (REYI -.407)••^,6^ 

raspk*rspan*rspan/rarea 

RCL8*?. *PI*RASPR/ « RASPR^3. » 
ri  rFr»OQ*EWOFAC*PCta*EFFANC 

CO=7. •CFR^PI8*T0VC (II *TOVC (II • (1 . ♦G*RSPAN/ (U*UII ♦ RCL B *E FF ANG*£FF AN 

•G 

IAPPF( 1 1 *XAPP( II 

YAPPF(II«VAPP(II  - (SPANdl  - .S*RSPANI  •RSIN(  I) 

7APPFm*ZAPP(IM  (SPAN  (I  l>  .5*R$PANI  •RC0S(  II  ♦YAPPF  (II  • PH  I - X APPF  C 1 1 • 
• theta 

FX(M  «-CC*QQ 

FYUI  »FLIFT*RCOS(I  I 

F7fll*FLIFT*RSINIII 

FX(II*-7APPF(II*FY(II  ♦YAPPF(  II •FZ (II 
FN( II «ZAPPF (I  I *FX ( 1 1-XAPPF (II »FZ ( II 
FN(II  »-YAPPF(  II*FX  (II  tXAPPFdl  •FY(II 

14  CONTIMM^ 

IF  (ion.ne.iapnogi  return 

ITENP  ^♦NAPP 

call  ROLCHX  (1HS«1HE«1HS,1HP,1HL.1H1I 

NRITE  dCX,6l 

DO  15  I*  I ,NAPP 

ANGt  * ANu  INC (I  I *RAO 

ANG?*ANoCNT (II *RAO 

MR:TE  (I  ox,  71  l,ANGl,ANGe,F  Kdl  ,FY<II,F7(II  ,FK(II  ,FMdl  ,FNdl 

15  CONTINUE 
RE  TURN 

16  CALL  ROLCMX  d HS  , 1 HE  , 1 HS  , 1 HP  , 1 HL  , 1 HI  I 
MRIIE  (lOKfZI 

WRITE  dOX.ll 
WRITE  (IOX,3l  MUSF 
GO  TO  74 

17  NNOO*MOOE 

IF  (HUSE)  16,74, IS 
IS  IF  (NODE. Ge.-3t  GO  TO  19 

IF  (hOOE.GE,-7l  GO  TO  70 

10*107 


I 4() 


IF  (NOOE.GC.-ll)  GO  TO  Zl 
19  IO»IOX 

IF  (MODE. GE. -Ill  GO  TO  ^l 

CALL  ROLCHK  ( 1 H$ f 1 HE , 1 H$,l HP , 1 HL , 1 Hil 

WRITE  no,?) 

WRITE  (10,1) 

WRITE  (10,4)  HOOE 
NHOO>  0 
GO  TO  ?l 
?0  IO«IOY 

?1  CALL  ROLCHK  < 1 HS . 1 HE , I HS, 1 HP , 1 HL • IHl ) 

WRITE  (10,1) 

NN(X>E«IS1GN(NH00,1)«1 
IHOVa  HOO ( NMOOE • 4 ) ♦ 1 
GO  TO  (23,??,?3*??l , INOX 
22  call  ROLCHK  ( 1 H$ , 1 HE , IHS, 1 HP , 1 HL , 1 HI ) 

WRITE  (10,91  HUSE 
?3  MUSE»0 

CALL  ROLCHK  ( I HS  , 1 HE  , 1 HS  , I HP  , I HL  , 1 HI  I 

CALL  ROLCHK  ( 1 HW , 1 HA , 1 HV • 1 HE , 1 HA , IH  ) 

24  RETURN 

ENO 


P90GHAH  POLCiL I OUT PUT , T APt 6* OU TPU T , T AP€  3 * T APE  9 * 
• TAPE  10 •TAPEll•TAPel^•TAPel3,T  APE14,TAPE15I 


conhon/apnogo/ix 

0 ( 

60) 

CONMON/A  PPNOG/ IX 

l( 

262) 

CONHON/CGLOC  /IX 

2 ( 

2) 

CONNON/ELAGS  /IX 

3 ( 

4) 

CONNON/PHYCON/IX 

4 ( 

7) 

common/sescom/ix 

5 ( 

25) 

COHHON/VARRLE /IX 

6 ( 

15) 

CONMON/USEO03/IX 

7 ( 

1) 

HOflE*2  I 

REWIND  13 
REMIND  14 
REMIND  15 
DO  10  1=1*13 
J«  J-l 

DO  1000  K>1«  60 

IX  000  = 1 

1000  continue 

DO  1001  K«l*  262 
IX  l<tO  = l 

1001  CONTINUE 

DO  1002  2 

IX  2( Kl «1 

1002  CONTINUE 

DO  1003  Ksl,  4* 

rx  3(10*  1 

1003  CONTINUE 

DO  1004  K*l,  7 

IX  4(XI*1 

1004  continue 

DO  1005  X«l*  25 

IX  5(KI*1 

1005  continue 

IX  5( 17) « 10 
IX  5(?0)*11 
IX  5(23) *1? 

00  1006  x*l,  15 

IX  6(iO>  1 

1006  continue 

DO  1007  K*l,  1 

IX  7(lO«l 
100  7 continue 

call  APN0GA(0*D*0«0*0*0*0« J) 
IFfMODF  .EQ.  3)00  TO  5 
call  HOOIO(J) 

5 ENDEILE  3 

10  continue 
call  CMPARf 
REiilNO  3 
REMIND  13 
REMIND  14 
REWIND  15 
STOP 
END 


PESULTS  OF  ROLL  CALL  CMCCK 
ALL  subroutines  MERE  CALLED  IN  THE  ROLL  CALL  NODE 


OUTPUT  OEVXCE  < 


MODE  iNOEXs  0 

subroutine  APNOGA DRAFT.  Ol*01-0Sl<»FV 

USED  1 TINES  NITN  MODE  INDEX  GREATER  THAN  ZERO 


NODE  INOEXS  -1 

SUBROUTINE  APNO'OA DRAFT.  Ol  • 0 1- 0 Si  <•  7 1* 


node  index* 

SUBROUTINE  APNOGA DRAFT.  01  - 0 0 5 1 7 4 

USED  1 tines  NTTM  mode  INDEX  GREATER  THAN  ZERO 


SUBROUTINE 


node  INOtX*  -3 
APNOGA 


DRAFT. 


01 -01-051474 


NODE  IN0EX*-12 


•••ERROR*** 


SUBROUTINE  APNOGA DRAFT.  01  -01-051  47  4 

INPROPFR  hoof  index  of  -12  ENCOUNTERED. 

ZERO  SUBSTITUTED.  ROLL  CALL  CONTINUES. 

SUBROUTINE  APNOGA DRAFT.  01  -01-051474 

USED  1 TINES  NITH  NODE  INDEX  GREATER  THAN  ZERO 


OUTPUT  Device  V 


none  Index*  -«* 

SUBPOUT  I Nf  APNOG* OP  AFT.  01  -Ol-OSl  V7% 

USED  1 Tines  MTTH  HOOe  INOex  GPCATEP  than  zepo 


MODE  IHDP  X«  -5 

SUBROUTINE  APNOGA DRAFT.  01  -01-0S1N7P 


HOOF  INDEX*  -6 

SUBROUTINE  APNOGA DRAFT.  Ol-Ot*OStW7P 

USED  1 Tines  MITH  node  INDEX  GREATER  THAN  ZERO 


HOOE  INDEX*  -7 

SUBROUTINE  APNOGA DRAFT.  Ot  - 0 1-0 SI  «i7 <• 


OUTPUT  DEVICE  Z 


NODE  INDEX*  -8 

SUBROUTINE  APNOGA DRAFT.  O1-01-0S1N7R 

USED  1 tines  with  node  INDEX  GREATER  THAN  ZERO 


HOOE  INDEX*  -R 

subroutine  APNOGA.  . DRAFT.  O1-01-0S1N7G 


NODE  INOEX**i| 

SUBROUTINE  APNOGA DRAFT.  OI-01-0S1R7R 

USED  1 TINES  tflTH  HOOE  INDEX  GREATER  THAN  ZERO 


HOOE  INDEX*- 11 

SUBROUTINE  APNOGA DRAFT.  01-01-051R7% 


14/4 


i 


Audit,  Flow  Analysis,  and  Roll  Call  (Mode=3)  of  a SESCOMP  Utility  Module 


r 


I 

I 

I 

I 

I 


, I 


rUNCTIOH  ISEOVfl.N.LOC.HBCT.MOOEl 

C function  ISEOV SESCOHP.US-QZ-oroi7S 

C • THIS  PROGRAM  UNIT  IS  PROVIDED  BY  • 

C • • 

C • department  oe  tne  navy  • 

C • SUREACE  EEEECT  SHIPS  PROJECT  • 

C • P.O.  BOX  34«.01  • 

C > BETHESDA,  MARYLAND  ZOOtA  • 

C • • 

C • REEERENCE--  • 

C • MODULE  VERSION  MANUAL  - BUEEEREO  INTEGER  DIVISION  • 

C 


C.....  ISEOV-A  SESCOMP  BUEEEREO  EUNCTION  NHICM  EINOS  THE  DUOTIENT 
C OE  TNO  INTEGERS 

c»*»»»»»**i-tme  integer  OIVIOENO 
(.........H-thE  integer  divisor 

C.....  lOC-LOCATION  code  oe  EUNCTION  REEERENCE  IN  REEERENCING 
C MODULE.  .GT.  0 and  .LE.  10 

C»»*»»  NBCT-auEEER-TRACING  ARRAY 


I 

I 


IAS 


> 


1 


^••••••••hoOE'POSITIVE  integer  IMOICRTES  C0HPUI»TI0N»L  mode 

C .EE.  0 4WO  .GE.  -11  INOICRTES  ROIL-CALL  NODE 

C SEE  utility  module  ROLCOL  for  an  EXPLANATION  OF 

c roll-call  node  values 

c NO  buffered  functions  are  referenced  by  this  version. 

C CATEGORY  1 common 

COMMON  /sescomecase 113) ,ina,inb,inc,iox,npagx,linx,ioy,npagy,liny.ioz,npagz.linz 

(;•••••  CATEGORY  Z COMMON 

common/iseovi/nuse 

C»*»»»»»»»NUSE-USE -COUNT  index 

C .'POSITIVE  INTEGER  INDICATES  NUMBER  OF  TINES  MODULE  HAS 

C BEEN  called  NITH  A POSITIVE  MODE  INDEX 

C >0  INDICATES  MODULE  HAS  NOT  BEEN  CALLED  OR 

C HAS  PREVIOUSLY  BEEN  CALLED  IN  THE 

C ROLL-CALL  MODE 

1 FORMAT  (5X,  13AI.I 
i FORMAT (IZH  •••ERROR***) 

3 FORMAT  ISX.ZQH  USE-COUNT  INDEX  IS  .IZ.ZIM  CHECK  INITIALIZATION) 

DIMENSION  NBCT  (?0.  10)  .MIFI13) 

DATA  MIF/GHFUNC ,GMT ION.GH  ISE.GHOV. . .G*GH. . . . , GMSESC. GM DNP. , GHUS-0 . GHZ* 0 7 , GHO 1 ZSZ 

C*»***CMFCK  MODE 

IFtMODE.LT.ll  GO  TO  9900 


GRAPH  HAS  BEEN  PLACED  INTO  MEMORY 


FOR  NEGATIVE  USE  COUNT 
IF(NUSE.CE.0I  go  to  10 

C*****PRtNT  ERROR  MESSAGE  FOR  NEGATIVE  USE  COUNT 
call  SESPLlUOY,3t3> 

CALL  ROLCMK  UHStlHE,  1HS,IHP,1HL  .IHII 

MRITE(IOX,2l 

MRITEdOX,!)  NIF 

NRITE(IOX,3)  NUSE 

NUSEsO 

NUSE*0 

10  NUSe»MUSE*l 
10  NUSE*NUSE^1 

IF(N.NE.0>  GO  TO  so 

ISEOV*l 

ISEOV*l 

IFaOC.GT.O.ANO.LOC.LE.lO)  GO  TO  ?0 

IFILOC.LE.Q)  GO  TO  21 

NBCT  (lltlO)  «NBCT  (11  ,1  OMl 
NBCT(11,10>«NBCT(11«10)«1 

CO  TO  9999 

?1  NBCT(ll,llaNBCT(llt  n»l 
21  NBCT( 11, II *NBCT (Ilf  1) ♦! 

CO  TO  9999 

20  NBCT(11,L0CI*NBCT(11,L0CM1 
20  NBCT(11,L0CI  >N6CT(1  ULOC)  ♦! 


GO  TO  9999 


50  ISEOV«I/M 
50  ISEO»*l/H 

GO  TO  9999 

•••••  REFERENCE  TO  tOlL-C»LL  UTILITY  MODULE 

9908  COLL  9OLCOLtMUSE,M8CT,0,MIF,MOOE» 

9980  COLL  90LCHK  (1  HR ,1H 0 . 1 HL , IHC . IMO . IML I 

•••••COLL  RCFEREMCEO  MODULES  IM  THE  ROLL -COLL  MODE 


COLL  SESPLIIIOX.I.MOOEI 

COLL  ROLCHR  (IMS.lHE.lHStlMR.tHLtlMlI 


STN60L  TABLE  FOR  MODULE  ISEOV 


VARIABLES 


NAHE 

TYPE 

RCLOCAtTION 

X 

INTEOR 

Fb  p. 

N 

INTEGR 

F.  P. 

LOC 

IHTEGR 

F.  P. 

N8CT 

INTEGR 

ARRAY  ^ 

F.  Pb 

HOOE 

INTEGR 

F.  P. 

lOX 

INTEGR 

SESCON 

NUSE 

INTEGR 

ISEOVl 

NIF 

INTEGR 

ARRAY  1 

ISFOV 

INTEGR 

NAME 

EXTERNALS 

TYPE 

ARG5 

SESPLl 

3 

ROLCOL 

5 

STATENENT 

LABELS 

1 

3 99«S 

10 

50 

^0 

ZX  9999 

COMMON  BLOCKS 
NAME  LENGTH 

SESCOM  2f 

ISEOVl  1 


RESULTS  OF  FLOM  ANALYSIS 


NO  ERRORS  FOUND 


NUMBER  OF  PATHS  CHECKED-  ■» 


FLOM  ANALYSIS  TOOK 


.I3B  CP  SECONDS 


149 


1 


CLOBtL  REFERENCE  TABLE 


EXTERNAL  REFERENCES 
SESPLl  SUBROUTINE  NODULE 

ROLCOL  SUBROUTINE  NOOULE 


LABE 
BLOCK  NANE 
SESCON 
ISEOKl 


LLEO  CONHON  BLOCKS 

SIZE  CLASS 

ZS  CATE60RY 

1 CATECORT 


1 

Z 


SUBROUTINES  ENCOUNTERED 
ISEOV  FUNCTION  NOOULE 


FUNCTION  ISEOVII.N.LOC.NBCT.HOOE) 

COHNON  /SE SCON /CASE  «1 3 I . INA, INB, INC.IOX .NRACX ,LINX,I0T.NRA6T,L INr. 
•lOZ.NPAOZ.LINZ 

connon/iseovi/nuse 

1 FORNAKSX.IIAAI 
Z FORNATtlZM  •••ERROR»»»l 

3 FORNAT ISX.ZON  USE'COUNT  INDEX  IS  .IZ.ZIH  CHECK  INITIALIZATION! 
OINENSION  NBCT  IZO.  10)  .NIFI13) 

OA  TA  NIF/I.NFUNC<ANTION.IiH  ISE  .AMOV.  . ..  t AHSESC  t ANONP.  , AHUS-0 

•,AMZ-07,AN01Z5/ 

IFINOOE .lT.1*  CO  TO  998S 

IFCNUSE  .CE.OI  go  to  10 

CALL  ROLCHK  ( IHS 1 1 HE , INS 1 1 NP , 1 ML . IHl I 

MRITE IIOX.ZI 

MRITEdOX.ll  NIF 

MRITE  IIOX,3)  NUSE 

NUSE*0 

10  NUSE*NUSE*1 

IFIN.NE.O)  60  TO  90 
ISF09«1 

IFILOC.CT.O.ANO.LOC.LE.IOI  so  to  zo 
IFILOC.LE.OI  CO  TO  Z1 
NBCT 1 1 1, 101 «NBCT (11,1 01*1 
CO  TO  9999 

Z1  NBCT(11,1I>NBCTI11.1!*1 
GO  TO  9999 

ZO  NBCTIll.LOCl'NBCmi.LOCI*! 

CO  TO  9999 
90  ISEOV*I/N 
CO  TO  9999 

99BB  CALL  ROLCHK  1 1 HR.l HO,  IHL . 1 HC . IHO . IHLI 
CALL  ROLCHK  ( IHS, IHE, INS, IMP, IHL , INI! 

9999  RETURN 
END 


I ')() 


d 


I 


PPOGff AN  ROLCAL ( OUTPUT , T APf 6 * OU T PUT , T APE  3 t TAPE  9, 
• T APf  1 0*  TAPE  1 I , TAPE  1?  , TAF^  13,T  APE1<*,TAPE15) 
COHHON/StSCOM/m  0(  26) 

COHMON/ISEOVI/II  l(  1) 

J»1 

NOOf  = 5 
»E«INO  13 
PEWINO  I** 

PPnINO  15 
00  10  1=1,13 
Js  J-  1 

00  1000  Ksl,  ^5 

I»  0 < to  = I 

1000  continue 

I*  0(  l/)  = 10 
I*  0( ^0I =11 
IX  0(?3I =1? 

00  1001  K=l,  I 

IX  l(X>sl 

1001  continue 

call  ISEOV  (0,0,0,0,JI 
IFCHOOE  .EQ.  3»GO  TO  5 
call  MOOIOIJl 
5 ENOFIlE  3 

10  continue 

CALL  CHPARF 
REMIND  3 
• RFMINO  13 
REMIND  14 
remind  15 
STOP 
END 


ALL  subroutines  MERE  CALLED  IH  THE  ROLL  CALL  NODE 


\'}\ 


4 


AudJ^t  and  Flow  Anal^^sis  of  Ancj JJajX 


subroutine  C01EL» 


c 


C»TE60RT  1 CONHON  BLOCHS 


CONNON  /COLUHN/  IVERT,IL*TRL 

COMMON  /SESCOM/  CISE  tl3) , IN*. IMB. INC, lOX.NPtGX, LINK, lOY.NPRCY, liny, lOZtNPAGZtLINZ 


COMMON  /UNITS/  I SI , ISZ , IS3, ISM 


1 FORMAT  (IH  /Six, ZZHVERTICAL  PLANE  SUMMARY// 1 0 X , AHTIME , ZX , SHMAVE  AMP , T X, SHOR AFT ,9X, SH THEY A,SX , 1 
OMGAGE  PRESS, II, 9HBOM  ACCEL, SX,9HC  C ACCE L ,AX, ZNF AN  PNR/lOX , 3HSEC , IIX ,ZHET . 11 X , IH  F T ,11X , 3HOEG , 1 IX , 3 
HPSF,10X,tM&,lSX,lMG,llX,ZMMP/) 


? FORMAT  I 7X,FT.Z,  7X,F6. 3,TX,F7.  3,Z  (TX,F6.ZI  ,Z  (7X,F6.3I  .rX.FZ.ll 


3 FORMAT  IlH  /33X,Z1HLATERAL  PLANE  SUMMARY//!  X , AH  TIME  , 1 OX  , 3HPHI  , 9X  , SHBC  TAS  , 6X  , 9HLAT  ACCEL. IX, IHU 

,GX,iihtuRN  radius, 6X, SHYAN  RATE,17H  rudder  ANGLE/10X,3HSEC,10X,3HOEG,10X,3HDEG,11X,1HG,11X,3hFP 

S,10X,?hft,10X,7HOEG/SEC, tOX,3HOEG/) 


A 


DATA  EOF/3HEOF/ 


IF  MVERT.NE.n  GO  TO  7 


HRITE  (ISII  (EOF,I*l,8) 


END  file  ISl 


REMIND  ISl 

9 call  SESPLl  II0X,6,ZI 

9 CALLSESPLl«IOX,B,ZI 

MRITE  (IOX,li 

« READ  IISII  tine, ETA, Z, THETA, PB.BOMACC, ACC, FANPMR 


['■>2 


IF  ITINE.CQ.EOFI  GO  TO  7 


MKITE  (lOl.tt  Tt»C,ET*,Z,THETk.rB.80M«CC.tCC.r«NPMl 

Lim«LINX*l 

LIN*«LIN»*1 

IE  ILINX.EQ.fOl  60  TO  i 
GO  TO  6 

T IF  (ILATRL.HE.lt  GO  TO  1« 

WRITE  (IS7I  (E0F,I>1,8I 
EMO  file  IS7 
REHIMO  IS? 

S CALL  SESPLl  (IOX.6,71 

» CALLSESPLHIQ*,G,7» 

WRITE  (I0X.3I 

9 READ  (IS7I  TIME. PHI, BETAS. ACCLAT.U.TRAOUS.R.P'.iOAWG 

IF  (TIME.EQ.EOFI  GO  TO  lO 

WRITE  (IOX,AI  TltC, PHI, BETAS, ACCLAT.U.TRAOJS.R.RUOANG 

LIHX»L  IHXH 
LIMX-LINXH 

IF  (LINX.EQ.BOI  GO  TO  8 
GO  TO  9 

II  REWIND  ISl 

REWIND  IS? 

return 

END 


1 't  ) 


I 


SYHBOt  TA8LC  FOR  MODULE  COLFLA 


VARIABLES 


NAHI 

TYPE 

reloc»tion 

I YFRT 

INTEGR 

COUUHH 

ILATRL 

INTEGR 

COLUMN 

lox 

INTEGR 

SESCOM 

LI  NX 

INTEGR 

SESCON 

ISl 

INTEGR 

AINITS 

IS2 

INTE  R 

UNITS 

EOF 

real 

I 

INTEGR 

TIM«“ 

REAL 

ETA 

REAL 

2 

REAL 

theta 

REAL 

PB 

REAL 

90MACC 

REAL 

ACC 

REAL 

F ANPMR 

real 

PHI 

REAL 

BETAS 

REAL 

ACCLAT 

REAL 

U 

REAL 

TRAOUS 

REAL 

R 

REAL 

RUOANG 

REAL 

EXTERNALS 

NAME  TYPE 

SESPLl 


ARCS 

3 


STATEMENT  LABELS 

1 Z Z k 7 

5 6 10  8 9 


i 

1 


COMMON  BLOCKS 
NAME  LENGTH 

COLUMN 
SESCON 
UNITS 


2 

25 


\ 


COMMON  BLOCK  UNITS  HAS  INCORRECT  SIZE 


-4 


SULTS 


NO  ERRO‘?S 


NUHfjee  OF 


OF  FLOW  *NALVSIS 


FOUND 


PATHS  CHECKFD-  k 


FLOW  analysis  took  .OSO  CP  SECONDS 


15S 


d 


Audit  and  Flow  Analysis^  of  _Extraordina ry  Subrouti ne_IN0UT 


SU*^POUTInF  1 NOnT 


COHMCN  /SESrOM/  CASt  tn»  t IN*  ,1  Nfl,  INC  tIO»,NP*r*  ,t  INK,  in  Y.NOfiGy,  LINY  , I 07tNP*r,7,L  I N7 


COHmCN  /UNITS/  I51,IS^,IS3*IS4 


INA»5 

INA>5 


1NB>10 

INB«10 


I0X«6 

10I*fe 


lOY-B 

I0V»8 


IOf»fe 

IO?«fe 


ISI«1 

ISl»l 


IS?»? 

IS^•^ 


ISJ»AA 

ISJ*«»w 


IS%«3 

IS*i»3 


RfTUPN 


FHO 


) ^)h 


SVHROl  TftRLF  fOP  MOnUL^  INOUT 
VAPIftBLES 


NAMf 

TYPf 

P*‘LOCATION 

I NA 

I NTC“GP 

SFSCON 

I NP 

INTCGO 

sescoH 

10* 

INTf GP 

SE  SCt)M 

TOY 

I NTFGP 

srscoH 

107 

INT^CP 

SFSCOM 

ISl 

I NTFGP 

UNITS 

IS? 

I NT  p r,  p 

UNITS 

1ST 

I NTFGP 

UNITS 

ist 

I NT^CP 

UNITS 

CONhON 

BLOCKS 

NA**f 

L'’NGTM 

SFSCOH 

?S 

UNITS 

4 

CC»“-ON  '^LCr«  L'NTTS  MAS  INCOPPeCT  SI?P 


Pf^ULTS  CF  FLOW  ANALYSIS 


WO  «^PPOPS  FOUND 


NUMPfP  OF  PATMS  CMCr»(FO-  t 


FLOW  analysis  took  3.000  CP  SfCONOS 


Try 


1S7 


I 


Audit  and  Fk)w  Analysis  of  Extraordi nary  Subroutine_  START 


SUBHOUTINE  ST»»T 
COHHON  /USEOOl/  HUSOl 
coHHON  /usEoo?/  ►lusoa 
COMHON  /USEDOJ/  HUS03 
COMHON  /USEOOU/  HUSO*. 
CONHON  /USEO06/  HUS06 

COHMON  /ustnoe/  mjsoe 

COHHOH  /USEOlO/  MUSIO 
COMMON  /USEOll/  MUSll 
COMMON  /USEOIN/  MUSIN 
COMMON  /USEDir/  HUS17 
COMMON  /USE018/  MUSIB 
COMMON  /USE019/  MUS19 


COMMON  /USE020/  MUS20 


I 


COMMON  /PACEl/  NUSE.NQOLIC 


NUSE«0 

NUSE«0 


NROLLC«0 

NROLLC«0 


MUS01«0 

MUS0l»0 


MUS0?«O 

MUS0?*0 


I 


MUS03«0 

HUS03«0 


MUSO%«0 

NUSOVaO 


MUS06«0 

MUS06«0 


HUS08>0 

HUS06«0 


HUS10*0 

MUS10*0 


Hasii«o 

HU$11«0 


NUS1%>0 

MUS1^«0 


Musir*o 

HUSlT-0 


Mu$ia«o 

NUS18«0 


HUS19«0 

MUS19«0 


HUS?0«0 

NUS?0«l 


HE TU*H 


EMO 


I 


1 Vi 


•4  I 


SYNSOL  f*BLE  for  HOOULE  START 


VARIABLES 


NAHE 

TYPE 

RELOCATION 

NUS91 

INTEOR 

USE  OB  I 

HUSO? 

INTECR 

USE002 

MUS05 

INTECP 

useoo] 

HUS0<» 

INTECR 

USEOOA 

MUSOb 

INTECR 

USEOOA 

HUSO0 

INTECR 

uSEooa 

HUSH 

INTECR 

USEOll 

HUSlb 

INTECR 

USEOIA 

Nusir 

INTECR 

usEotr 

NUS18 

INTECR 

USEOIB 

HUS19 

INTECR 

USEOIS 

HUS^0 

INTECR 

USCDZI 

NUSE 

INTECR 

PACEl 

N90LLC 

INTECR 

PACEl 

COMHON 

BLOCKS 

NAME 

LENCTH 

USEOOl 

1 

USEOO 2 

1 

USEOO 3 

1 

USEOOA 

1 

USEOOb 

1 

USEOO 0 

1 

USEOlO 

1 

USEOll 

1 

USEOIA 

1 

USE017 

1 

usEoia 

t 

USEOlO 

1 

USE020 

I 

PA6E1 

2 

THE  COHNON  BLOCK  SESCOH  DOES  NOT  APPEAR  IN  THIS  PROCRAN 


RESULTS  OF  FLOW  ANALYSIS 


NO  ENPORS  FOUNO 


NUHBER  OF  PATHS  CHECKED-  I 


FLON  ANALYSIS  TOOK 


Btl  CP  SECONDS 


Audit  of  d_  BLOCK  DATA  _Sub£ro£rajn 


RLOCK  OAT* 

COHHON  /ArpOOI/ 

COHHCN  /IceoSI/ 

COHMCM  /iPPNOG/ 

COHHCN  /aPNOGO/  75fUC» 

COHHCN  /PNCO/  7? *?» 

COHMCN  /fiOMSLI/  7?o(*'9» 

COHMCN  /POMSLO/  7S*il<iOI 

ccHMCN  /rcior/  7f7e?> 

COHMCN  /COLUMN/  73(71 
COHHCN  /FQNCO/  77IU1) 

COHHCN  /FNCTnI/  74SI1907I 
COHHCN  /r»NI/  7^6I3S%I 

rcHMCN  /rtac^/  ijoe , icase , istep , ir»p 

COHHCN  /FPOUOE/  71*.(7» 

COHHCN  /GOON/  73C<3I 
COHHCN  /MELHO/  7f?<*.C9» 

COHHCN  /LCANPP/  7?? 

COHHCN  /lO*OS/  )THI 
COHHCN  /HASSrS/  7?3«et?> 


161 


«OHMCN  7?«*(3n 

coH«CN  /KSiriM/  7?5i??> 

C01HCN  /MMiye-/ 

COHHCN  /OPTinw/  7?7(3) 

COHHCN  /PHrCON/  r,,  frHO,  MPMOtf  NUtPHOIWP*  PINP,  r,  #>* 

COH-CN  /PPJNT/  I SES, 1 INTCP.lPHt 
COHHCN  /POOPI/  7?9I8I 

CCHNCN  /SESCOH/  C*^E  U 3)*>Nl,lNB,INr,lo».NPir.K,LIMlt,'lOr,NP*GY,LINY,I07*NPAr,7,LlN7 

rOlMCH  /5T0WLI/  731 *?7» 

COHHCN  /SLOPE/  7.ie<2» 

COMHCN  /SPofcY/  75?(5*» 

COMHCN  /STNSLI/  73*f30» 

CCMHCN  /STNStO/  75*(i.C» 

COHNCN  /times/  73315) 

COMMCN  /TOPQUf/  734I27I 
COMMCN  /VtPBLF/  7**l(15) 

COMHCN  /HIVE/  7*i?IM 
COMMCN  /M4VESI/  7eC(79) 

08TA  71/?1«?.C/ 

0*T»  7?/?*0,0/ 

OiTA  73/?*0.0/ 


OATA  77/l.l*'5,C/ 


I 

I 


oara  7iu/’»o  .C/ 

OftTa  7??/o.c/ 

TflTa  771/^17*O.C/ 

OflTA  7?(*/3f-*3.  C/ 

nara  7?5/?E*:.C/ 

oara  7?fe/6*3.c/ 

oara  7?7/^*0.0/ 

nara  7?q/i .F 6, 7* c . c / 

oara  7ic/3.r/ 
i 1ST  SI7FS  nc  NOT  MBirH 

oara  7ii/?7*o,o/ 
oara  733/5*0.0/ 
oara  73i./?7*o.P/ 
naia  736/2*0.0/ 
nara  735/3n*o.o/ 
naia  7<»i/i5*o.c/ 
naTa  742/6*0.0/ 
oara  745/i507*c. c/ 
oara  746/354*0.0/ 
oara  75C/5*o.o/ 
oara  754/40*0.0/ 


oara  755/40*0.0/ 


nata  7*^e/60»o.«/ 


naTa  7*-7/?*o.C/ 

''aTa  7^9/S^*)*C/ 

Data  7«  c "i . r/ 

Tara  /►  * z?#*?  *0 . 0 / 
nara  /un<^*o  ,0  / 

oar  a rNUt^INc , ohct^ip  • r,  an/ 1,  - s,  ?i  i #»* , , oo  ? 17« , i ,4,/ 

DaTa  casf/n*4« 

oara  iNa,iN^,i*^  ,iok  ,NPa&K,L  Inx.ioy,  NPaGY.LlNV  , io7,NPar.?,LlN7/i?*o/ 

oara  ijop,  ir  as*" . i$t  ep  , iepp/4*o/ 
oaTa  ***1/0.0/ 

Data  ISES. IINTOP,IPHS/0,0,0/ 

ENf) 


SYMBOL  Ta«tE  POP  PLOCK  oaia 


vAPiaeies 


TYPE 


71 

REAL 

7SC 

PEAL 

7bl 

Pf  AL 

PEAL 

7? 

peal 

750 

PEAL 

7S«. 

peal 

7S7 

PEAL 

73 

PEAL 

77 

peal 

7UE 

PEAL 

7«*f 

PEAL 

IJOP 

INTET.P 

Tcatf 

intfgp 

ISTf  P 

INTEGP 

UPP 

INTEGP 

71  *. 

peal 

71C 

peal 

76? 

PE  AL 

7?? 

PEAL 

YHI 

PEAL 

APPAY 

1 

RELOCATION 

AEPOOI 

APPAY 

1 

AEROSI 

APPAY 

1 

APPNOC 

APPAY 

1 

APNOGO 

APPAY 

1 

BMCO 

APPAY 

1 

POHSL  r 

APPAY 

1 

80WSLO 

APPAY 

1 

cgloc 

APPAY 

1 

COLUMN 

APPAY 

1 

FONCO 

APPAY 

1 

ENGINI 

APPAY 

1 

EANI 

APPAY 

1 

flags 

FLAGS 

FLAGS 

flags 

rpouOE 

APPAY 

1 

GBOM 

APPAY 

1 

helms 

LEAPEP 

LOADS 

Pf  4L 

APQAT 

1 

NAS*“f  S 

PF  4L 

APOAr 

1 

HATPIX 

pc  Al 

APOAV 

t 

H'lTDM 

OF  »L 

APPA  r 

1 

HwA  VF 

177 

Pf  AL 

AP9A  Y 

t 

OPT  TON 

f Nil 

PF  At 

pmycOn 

CMCiNf 

Pf  AL 

PMYCON 

F I NF 

Of  AL 

PMYCON 

GAh 

Ff  AL 

PWYCON 

iSf  s 

INTpGP 

PP  TNT 

I I ».  T r,p 

TMFGO 

point 

IPHS 

I NTf  GP 

POINT 

7?«> 

OF  AL 

APPA  Y 

1 

PPOPI 

CA*‘F 

Ot  AL 

AOPA  Y 

1 

SF  SCON 

TNA 

I N T F r P 

SFSCON 

INP 

I NT  FTP 

SFSCOM 

INC 

I NTFGC 

SF’SCON 

10* 

I NTFf,C 

^ESCON 

NP£C» 

I NTf GO 

SCON 

1 INlf 

Intfgp 

$FsroN 

lOV 

INTFgp 

Sf’SCON 

KP£  GV 

U'TFGP 

$f SCON 

I ktfGp 

SFSCON 

107 

TNTFGP 

srscoN 

NPfiG  7 

I NTF^o 

srscoN 

L IN7 

INTFGP 

SFSCON 

7Y1 

PFAL 

AOOAY 

1 

sinwL I 

7 3f. 

OF  AL 

A09A  Y 

1 

SLOPS 

PFAL 

APPA  Y 

1 

stnsli 

PFAL 

APPA  Y 

1 

stnslo 

7 3 3 

Of  AL 

APPA  Y 

1 

TINFS 

7 3u 

Of  Al 

AP9AY 

1 

TOPQUF* 

7(.l 

Of  AL 

APPA  Y 

1 

VAPC^LS 

7^? 

PFAL 

APpA  V 

1 

NA  VF 

7F.0 

OF  AL 

APPA  V 

1 

NAVESI 

roHMOK  RLOC*^^ 


NAHF 

L*‘NGTH 

AFPOOT 

’1 

AFpo^’I 

A 

APONOG 

A PNOGO 

flNCO 

7 

*^ONSL  t 

S9 

OOWSLO 

(*0 

CGLOC 

7 

COLUMN 

2 

FQNCO 

ui 

fnGINI 

ISO’ 

F ANI 

3S«. 

flagf 

k 

FPCUOF 

2 

GPOM 

3 

mflnS 

40  0 

LEA<fp 

1 

LOAOS 

1 

NASSES 

Al  2 

MA  TO  I Y 

36 

Nsrow 

?s 

MMA  VF 

6 

OPTION 

3 

pmyCCN 

T 

point 

3 

PPCPI 

« 

SFSCON 

•>5 

snwLi 

?i 

fLOPf 

2 

SFPA  Y 

>G 

S T NS  L I 

30 

stnslo 

40 

TiNf  c 

9 

TOOQU*’ 

27 

VAPC^LF 

IS 

NAVF 

6 

WAVE  ST 

79 

hftC'iKr,  - Viola'll  r»  '*C-MCN  nioctf  TOLUMN  00"S  NOT  60®'=’“  wTTm  TNTFprar^  OfrjNjTycN 


sr.  - vairiat'L  Tyrr  IS  roMHON  TONfO  no^c  ^OT  ao®“-  INTTP^aC 


Of  PIM  T I ' N 


wap'.JKr.  - V6Pia'»L'  TVPt  T»  rpMMCS  RLOr^  F NO  I M TO«’S  NOT  aOO'*C'  WTTh  iNTro^aO'  OfflNl^ION 


wBPsiKf.  - ^aPia*’L  tyff  i ».  co-^hcn  Rior*'  raNi  not  ao^fs*  .^TTm  ^NTcprar'’  ni^TNiTxf'K 


wapKjKO  - vapiara-  I‘  C0'^*^Cn  PiOC*<  wfL'*?  '^CfS  NOT  ao®ff  ^!Tm  ysT'^^ocar-  O^^'INITI  -s 


wap*.TNr.  - vapyaoL  ’vpf  in  tommon  oioc«'  opttok  nof*"  not  aco'*  ^ctm  TSTfpfacF  orcysiTi^N 


hapsi^f,  - vapiaf'L'’  in  och*-cn  oior.^  ppo®I  ''O''*^  sot  aooff  *<itw  rsTt'PFafE  offlNiTjCN 


naPNisr,  - vapyant,-  rypf  yn  rnnHOS  oloc*^  sinwtl  OC'S  not  a^pf*  4ITm  ysifPFac  OfflNiTjcN 


wapsiso  - vaoiapf  tvpf  in  ocm^^tn  oicri^  Sfpav  nof$  not  a.o"  wT’m  iNTfPFacf  offisy^ios 


Audit,  riow  Analysis,  and  Variabl^Precision  of  an  Executable  Program 


1 

f 


i 


PPOG»»M  micro ( INPUT, OUTPUT, T*Pf 5*1 npuT, T4PC6»0UTPUT I 
1C  FORMAT  I IMI , 1 OH  TRAPE2OI0#6»,«*MaPFA,i  ?*,5HtPOORI 
INTFGFP  OUT 
OljTsF 

GPAPM  MfiS  RCFN  PL4CEO  INTO  Mf  hQRT 
OUT*6 

MPITE(OUT,10) 

00  TO  I=ltl5 

N=2*  ’n-i » 

I-l I 

A=0.  0 

A*Q«Q 

M« 1. /float  ini 
M = QIREAL (1. /float  ini  I 

00  20  J«1.N 

FL»flOAT ( J-t I 

KL  *01RFAL IFL  OAT IJ-1 I *MI 

?'  A*A«IM/?.I« (FUNIFLI ♦FUN  I M* XL  I I 

NARNiNf.  - THIS  mOOULE  IS  NOT  IN  THE  SESCOMP  LIST 

2 0 A«QtREAL  lA^OtPEAL  UQIREAL  IW/2,  1 I • IQtPf  At  IF  VIH I X 1 1 * FUNI  01  RF  At  IN*XtH 
I I I I 

E«5.-A 

E«QlRFAtl5.-AI 

i:  nritecout,40in,a,f 

40  F0RHATua,Fi6.A,Fiq,ei 

this  statement  is  out  of  order 


STOP 

ENO 

warning  - THIS  HOOUIE  IS  NOT  IN  TmE  SESCOMP  LIST 


I 


K.7 


A 


<;ymbol  T4RL:  fOR  MOmjLE  MICRO 


yARIABLFS 

NAMf 

TYPf 

Rf  LOCATION 

OUT 

I NTEGR 

I 

TNTEGR 

N 

INTf GR 

A 

real 

W 

real 

J 

INTCGR 

XL 

real 

REAL 

ternals 

NA  ME 

TYPE 

ARGS 

el  oat 

real 

1 

FUN 

real 

1 

STATEMENT 

LAO^LG 

10 

30 

^Q  40 

TWF  common  flLOCX  'ESCOM  DOES  NOT  APPEAR  IN  THIS  PROGRAM 


J 

I 

I 

I 

i 

t 

! 

t 

} 

I 


»F*;Ul.TS  OF  FLOW  »N«LVSIS 


NO  fP»0«S  FOUNO 


9 OF  PUMS  CHfCKFO-  1 


FioM  •Ntivsis  TOOK  a. aoo  cp  seconds 


K.H 


rUNCTION  rUN«XI 


FUN»6.-6.*X**5, 

rUN»QlP€ AL  16. “OIPFAL (6. •QlOF AL (X*»S. m 


9CTURN 

FNO 


St»<ROL  TA^C*  TOP  HOnULf 


NAME 

Type 

VAPIAPLES 

•ELOCATION 

K 

PFAL 

F.  P. 

FUN 

PFAL 

THf  COHHON  *^L0CK  OOFS  NOT  aPPEAP  IN  THIS  P»OGOAH 


PFSULTS  OF  flow  ANALVSIS 


NO  PPPOPS  FOUNO 


NUNPtP  OF  PATHS  CMCrXfO-  I 


Flow  analysis  toox  o.aoo  cp  seconds 


global  9EFtPENCF  TABLF 


EXTFPNAL  PEFEPENCES 
FLOAT  ANSI  function 

FUN  USEP  SUPPLTFO 


SUBPOUTTHES  ENCOUNTEPFO 
N ICPO  US:  P SUPPL  TFO 

fun  USEP  SUPPL  TFO 


PeOGRAH  HiCffOl INPUT, OU TPUT,TAPf5» INPUT *TAOe6» OUTPUT! 

COHPLtX  QICONP 

OOUBLC  PRECISION  OlOPRE 

10  FORMAT  f IHl,  lOH  TPAPEZOIOf6*,*»HA?f  A,l?X,SMFPROftl 
INTEGER  OUT 
OUT«6 

MPITE IOUT,10> 

00  30  1*1, IS 

Ns  ?**ii-n 

AsQ.O 

MsQIPEAL  <1. /float  ini  I 

DO  30  J»1,N 

KLsQlPE  ALIFLOAT IJ-ll •«) 

3 0 A*01PEAL  U^QIREAL  UQIREAL  IN/2.  I)  • IQIPE  ALIFUN  I XL  I ♦FUNIQlPfAL  IN»XL  I I 
• II  II 

E»01PEAL  IS.-AI 
30  NPlTEfOUT,«»OIN,A,E 
40  format  I ie,F16. 8«E19. 61 
STOP 
FNO 


FUNCTION  FUNIXI 

COHPlEi  QICOMP 

double  precision  OlOPRF 

FUNsQIrEAL  C6.-Q1PEAL  IG.*Q1REAL  fx^^s.  1 1 1 

RETURN 

END 


40-Bit  Output 


TBlPEZOln  »PE»  ERBOB 


1 

3.00000000 

.?OOOOOOOE«01 

z 

4.<«06?0000 

. 5S37SQ00E»00 

4 

4.  04570313 

. 154?9688E*00 

4. qeiosBsr 

. 38940430E-0  1 

16 

4.qqo74?oo 

.975799566-0? 

3? 

4.  99755074 

.?441?57?E-0? 

64 

4.99930970 

.610798606-03 

l?B 

4.99904675 

. 153750186-03 

?56 

4. 99995900 

•40?833336-04 

SI? 

4.99990641 

.135898596-04 

10?4 

4.99990930 

. 1C6990  346-04 

?04S 

4.99990745 

.175535686-04 

4096 

4.99996600 

. 331997876-04 

819? 

4.99993301 

.661909586-04 

16384 

4. 99906607 

. 133931646-0  3 

39- Bi  t_  Output 


P8P670I0 

OBE* 

6RROP 

1 

3.000000Q0 

.?00000006»01 

? 

4. 40675000 

.593750006»00 

4 

4.  04570313 

. 154?96886^00 

8 

4.96105957 

. 389404306-01 

16 

4.99074700 

.975799566-0? 

3? 

4.99755047 

.?44«?556-0? 

64 

4. 99930057 

.611484056-03 

1?8 

4.99904539 

.154614456-03 

?56 

4.99995004 

.419616706-04 

51? 

4.99990747 

.175833706-04 

10?4 

4.99990001 

. 191976966-04 

?048 

4.99996537 

. 346307996-04 

4096 

4.99993449 

.655055056-04 

819? 

4.99906660 

.133395706-03 

16384 

4.99973707 

.767967486-03 

3^-Bit  Output 


RAP670I0 

«BE* 

EBROB 

1 

3.00000000 

.70000000E701 

7 

4.40675000 

.59ir5000E«00 

4 

4.84570113 

. 154?9688E»0D 

8 

4.96105957 

. 38940430E-01 

16 

4.99074165 

. 975815 17E -07 

3? 

4.99755800 

.74470073E-07 

64 

4. 99918738 

.61761654E-03 

178 

4. 99984336 

.15664101E-03 

756 

4.99995477 

.45776367E-04 

517 

4.99997475 

.757497fl7E-04 

1074 

4.99996316 

.36815670E-04 

7048 

4.99993193 

.68068504E-04 

4096 

4.99986589 

.13411045E-03 

019? 

4.99973015 

.76965141E-03 

16304 

4. 99946796 

.53701785E-03 

171 


37- Bi  t Ou tpu_t 


TR»PE70rn  «Bf* 


1 

3.88880888 

z 

4.48625808 

k 

4.84570313 

B 

4.96105957 

16 

4.  99024105 

32 

4.99755692 

64 

4.99938440 

1^8 

4. 99983954 

2S6 

4.99994548 

512 

4.99995756 

1024 

4. 99993'<38 

2046 

4. 99986792 

4096 

4.99973464 

8192 

4.99945807 

16384 

4.99891925 

3 6 - BJ  t Output 


P8P620in 

tREt 

1 

3.00080000 

2 

4.40625880 

4 

4.  84570313 

6 

4. 96105957 

16 

4.99024010 

32 

4.99  755526 

64 

4.99938154 

128 

4.99983263 

256 

4.99992990 

512 

4.99992371 

1024 

4.99986124 

2048 

4.99973631 

4096 

4. 99947166 

8192 

4.99891567 

16384 

4.99783564 

35-Bi t 0 u tp u t 


■P8PC70I0 

ARE  8 

1 

3.00000000 

2 

4.40625000 

4 

4. 84570313 

8 

4.96105957 

16 

4.99023724 

32 

4.99755096 

64 

4.99937153 

128 

4.99901705 

256 

4.  99989986 

512 

4.99985313 

1024 

4. 99971485 

2048 

4.9994  7166 

4096 

4.99892998 

8192 

4.99783134 

16304 

4.99563503 

ERROR 

.aoooooooE»oi 

.5q3f5000Em0 
. l5‘t?S68«E»00 
.3B9i»04]0E-S< 
.q7589*.93E-02 
.Z1.430752E-0? 
•6J559677E-03 
. 1S045S70E-8  3 
.54597855E-04 
.fc?438507E-04 
.69618225E-04 
.13208389E-03 
.26535988E-03 
.5419r543E-03 
.l0807514E-02 


ERROR 

.20000000E*81 
.S937S000E»OO 
. 16429688E*00 
. 38940430E-01 
.97599030E-02 
. 24447441E-Oe 
.63845779E-03 
.lt)T36984E-8  3 
.7009506ZE-04 
.76293949E-84 
.13B75961E-03 
.2b369095E'03 
. 5^83355  7E-»  3 
.10843277E-OZ 
. Z1643b39E'«Z 


ERROR 

.Z0l00(00E*tl 

.9937980«E»#0 

.184?9«B8E*0B 

.3B94a430E-ai 

.97»Z7648E-0Z 

.Z4498396E-aZ 

.»Za47lS7E-a3 

.18EH179E-83 

.188t39B8E*a3 

.t4aa6984E*a3 

.;a9i4a6?E-a3 

.5?a33»57E-8S 

.l8T8aZZ6E*aZ 

.ziaaaasbE-az 

.43«49«73E-ar 


^ - B i t Output 


TR8PF7OI0 

kRC* 

EURO# 

1 

]. 00000000 

.?OOOOOOOE*I 

3 

%.<i0620000 

.59375000E*I 

4 

<•.  S<>S7ail3 

. 156796S8E60 

8 

<». 96105957 

.38960630E'! 

16 

6.  9907J7I.7 

.976753?3E't 

33 

6.9975395? 

.76606797E-0 

64 

6.9993553? 

.666683S6E>0 

138 

6. 999788?8 

.71171570E*0 

396 

6.99983606 

. 16593933E-0 

913 

6.9997?7?5 

. 77775085E-0 

1034 

6.99966305 

.55696580E-0 

3048 

6.9989??35 

.10776570E** 

4096 

6.99786660 

.?1533966E-t 

8193 

6. 99567836 

.63716631E-I 

16384 

6.991705?? 

.87967«65E>I 

t jOujtj)u t 


Tr»PE70ID 

1 

2 

h 

8 

16 

33 

64 

138 

356 

913 

1034 

3048 

4096 

8193 

16384 


t _0U  t£U  t 


T»8Pf 3010 
1 

3 

4 
8 

16 

33 

64 

138 

396 

913 

1034 

3048 

4096 

8193 

16384 


E9R09 

3.00000000 

.30000000E»01 

4.40639000 

.993790I0€»80 

4.84970313 

•19439688E»00 

4.96189194 

•S8948099E-01 

4.99831149 

• 978891S3E-03 

4.  99747467 

.39393396E-03 

4. 9993933? 

.74768066E-03 

4.99997379 

.43734609E-03 

4.99941394 

•98746338E*83 

4.99894714 

•10938964E-03 

4.99781799 

. 31830068E-I3 

4. 99963999 

• 43640137E-83 

4.99114990 

. 88900977E*8? 

4.98319399 

• 17807007E-01 

4.96431091 

»39789490e-ll 

AREA 

ERROR 

3.00000000 

.?0000080E*01 

4.49635809 

. 59375000E*.0 

4. 64970313 

.156?968SE*tO 

4.96109997 

. 38960630E-I1 

4.99033679 

.97737566E-I? 

4.99793436 

.76757385E-8? 

4.99933480 

.67570167E-I3 

4.99973934 

.?76658?0E-03 

4. 99969463 

. 30517578E-83 

4.99943943 

.56657570E-S3 

4.99889799 

. 11B76675E-.? 

4.99784478 

.71553060E-8? 

4.99963973 

. 6379?7?5E-t? 

4.99130713 

. 87978777E-B? 

4.  98319399 

. 178070S7E-B1 

I ; } 


31-Bit  Output 


(f/LPEZOin 

A*f£A 

FPP09 

1 

3.  00000000 

.?OOOOOQOE«01 

2 

4*406?5000 

. 59375O00E^00 

k 

4.84570313 

.154?9688E»00 

S 

4.96101379 

. 38986?06E-Q1 

16 

4.99017334 

.98?6660?E-0? 

3? 

4. 9974C6Q1 

. ?5939941E-0? 

6^ 

4.99908447 

.9155?734E-03 

ICB 

4.99931335 

.686  64551E-0  3 

?56 

4.  99894714 

. 105?8564E-0? 

51? 

4, 99781799 

.?18?0068E-0? 

10?** 

4.  99565^  ?5 

.43487549E-0  ? 

?048 

4. 99116516 

.8834e369E-0? 

4096 

4. 98?Q8618 

. 17913818E-01 

819? 

4. 96430969 

.3569C308E-01 

16384 

4. 9?606^3 

.73913574E-01 

30-Bi  t_  Out£ut 


T98PE70I0 

AREA 

ERROR 

1 

3. 00000000 

.eoooooooE^oi 

? 

4.406?5000 

.5937500QE»00 

4' 

4.84570313 

. 154?9668E«^00 

8 

4. 96099854 

. 39001465E-Q1 

16 

4.99014?B? 

.98571777E-0? 

3? 

4.997?534? 

.?74658?0E-0? 

64 

4.99864033 

. 115966  80  E’O? 

1?8 

4.99880961 

. 11901855E-0? 

?56 

4. 997894?9 

. ?1457l?9E-0? 

51? 

4.9954??36 

.45776367E-0? 

10?4 

4.  991  36353 

.86364746E-0? 

?048 

4.98??08?5 

. 17791748E-01 

4096 

4. 96411133 

. 3588867?E-01 

819? 

4,9?617798 

. 738??0?1E-01 

16384 

4. 84579468 

. 154?053?E»00 
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